Shibboleth Developers

[Chad La Joie <>]

STOP! Before reading the main contents of this email please be sure you 
have read this:
http://groups.google.com/group/shibboleth-dev/browse_thread/thread/1fcab032218f8ffb 


This email will be a bit different than the previous two since the 
module discussed here, the consent engine, represents the only new 
subsystem to be added to the IdP in version 3.  So, the list of items 
below simply represents the coarse-grained list of features I currently 
have on my list.

To start with, though, let me define what I mean by "consent engine". 
The consent engine captures and records the user's consent for the 
release of information from the IdP to an SP.  That is, it asks the user 
the question "Is it okay to release attributes X, Y, Z to SP Foo?"  The 
consent engine is NOT, and will not be, an attribute filter policy 
management system.  Organizations must still determine what their 
policies are for data that they collect and maintain.  Now, their policy 
may be "release everything and let the user sort it out" but that is 
still a policy (no matter how lax and irresponsible).

So, the following are the high-level features currently planned for the 
default implementation of the consent engine:

- Ability to disable the engine for some or all SPs.  By default it will 
be enabled for all SPs.

- The ability to prompt a user to agree to a Terms-of-Use style 
document.  By default this will be off since there is no way to come up 
with a default document that would even be close to being okay with most 
deployers.  Once a user has agreed they will not be asked again until 
such time as the terms document changes.

- A page the displays the attributes to be released along with the 
service provider name/description.  Attribute name and description will 
be configured in the attribute resolver config, SP name and description 
will come from metadata.  All names and descriptions supports 
internationalization.

- Ability to require user consent for every login or to only ask again 
when the data (attribute values) to be sent to the SP changes.

- Ability to blacklist certain attributes such that they never appear on 
the user consent page.  For example, there is probably no need to get 
the user's consent to the release of a transient identifier.

- Ability to order non-blacklisted attributes.  So, for example, you can 
put surname after the given name.

- Logging of acceptance of the terms document and attribute release 
consent in the audit log.

- Ability to inject the consent engine in the back-channel and 
non-browser flows. If a user has not given prior consent the SP will not 
receive any attributes.  Obviously, from an operational standpoint, this 
option is mutually exclusive with the "always ask" option mentioned above.

- A simple management UI that allows the user to see and revoke (per-sp) 
their existing consent settings.  A link to this UI would probably be on 
the default login page so that users could always find it.  But it's 
easy to imagine linking to it from a organization portal as well.

Features I am considering but not yet committed:

- A uApprove DB -> IdP consent engine migration script.  It's possible 
that the consent engine may track enough new/differing data that this 
wouldn't possible.  I won't know for a while.

The following are features I've considered by ruled out for this release:

- Per-attribute or group-of-attribute consent.  This is something that 
various people have suggested with uApprove and a few people have tried 
(notably the Japanese federation).  Currently there are too few data 
points, and the ones that do exist vary wildly, to suggest whether users 
can understand this and what the best way to present it is.  That said, 
the underlying mechanisms in the IdP will support this (the engine just 
reports back a list of consented attributes) so people can and should 
experiment.

- 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.

- Any performance metrics, because I can't think of any that are 
relevant here.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered