Shibboleth Developers

[Peter Williams <>]

Perhaps play with the openid consent capability at myopenid.com. It's pretty 
simple (and is expressed in the notions of the UCI-class protocol itself, to 
some degree). Its worth looking at what others have done, in a compare and 
contrast exercise.

Much like the old NSA clipper/capstone crypto chip allowed one to define 
"personalities" of attributes to be released under a particular key 
management channel, so the myopenid engine define sets of claims/values to be 
released. The first time an assertion is to be released to a new SP (defined 
as an SP to which that user has not previously authorized the release of 
their assertion), a personality is selected or created for that channel. 
Having assigned the personality, one authorizes its release via the assertion 
process for the first run; and optionally sets auto-release for subsequent 
assertion process runs. By default, there is no auto-release, requiring the 
user to interactively authorize re-release of the personality bound to that 
SP. The use case for auto-release is basically classical constrained 
delegation (in any windows network intranet), in which third-party servers 
can act for the user in initiating security associations to fourth parties 
without the presence of a browser bearer/sessions (e.g. your web-ua pings 4 
pop3 legacy mailboxs periodically to aggregate email content access).



-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Halm Reusser
Sent: Monday, November 15, 2010 9:26 AM
To: 

Cc: 

Subject: Re: [Shib-Dev] [IdPv3] Consent Engine Work

Hi,

On 22.07.64 20:59, Chad La Joie wrote:
> Features I am considering but not yet committed:
>
> [...]
>
> - Global consent, meaning the ability to tick some box and never be 
> asked anything again regards of the SP or changes in the to-be-release 
> data. Again, as above, people are free to experiment with this feature 
> but I don't think there are enough data points to determine if users 
> really understand what this means or how to change such a setting.

Actually I was thinking a little bit about this. At my personal opinion I'm 
not very happy with the current implementation of this "feature".

The as-is situation (Arpviewer 1.x / uApprove 2.x) is like described by Chad. 
If a user checks this box, he gets never ever asked about consent again 
independently if he,

  ... accesses a new service provider
  ... accesses a already visited service provider including a new
      attribute to be released
  ... accesses a already visited service provider including a
      attribute already accepted to be released, but including different
      values.

Sounds not like a good privacy protection.

I can tell you my suggestion for this "feature". If a user checks such a box, 
it should mean "I accept that these attributes, which are listed above, 
including exact those values" might be released to every other service 
provider I access in the future". This is straight and clean.

This implies, the user has to confirm the attribute release again, if he 
access an already visited or new service provider and

  ... attributes, on which he did not give "global consent",
      will be released.

  ... attributes, on which he did give "global consent",
      but the values have changed will be released.

I'm looking forward to have a fruitful discussion about it.

-Halm