[OpenID] Tailoring headers to Consumers
Nate Klingenstein
ndk at internet2.edu
Mon Jun 2 04:31:36 UTC 2008
Shade & others,
For attribute release to RP's, we've always had what we termed
attribute release policies (ARP's) in Shibboleth. It's a key design
tenet. Some universities are uncomfortable releasing anything to any
provider that isn't trusted, even the fact that a user could
successfully authenticate. 2.0 has a ridiculously flexible
vocabulary and set of configuration for this.
Historically, we've done a very poor job allowing users to manage
their own ARP's. This is partially because we don't want students to
lock themselves out of resources required to complete a course,
causing a significant support burden by accident. It's also because
it hasn't been a pressing use case. That's changing.
We are actively working on giving users more control here when it's
appropriate. See, for example, SWITCH's work here, and the cool live
demo:
http://www.switch.ch/aai/support/tools/arpviewer.html
Discovery is a useful place to constrain which IdP's are selected by
the user, but requests are almost always unauthenticated, as Shade
mentions. Signing requests can be problematic to enable by default
because it's a relatively expensive, promiscuous operation for the
server and very cheap for a client, e.g. a DoS risk. For another
take on this, you might also look at Microsoft's CardSpace, which can
pre-filter the list of OP's presented by the identity selector by
specifying in the request what information is needed:
http://download.microsoft.com/download/1/1/a/11ac6505-
e4c0-4e05-987c-6f1d31855cd2/Identity-Selector-Interop-Profile-v1-Web-
Guide.pdf
Take care,
Nate.
> One thought is an optional "trusted sites list" HTML header in the
> claimed URI...
More information about the general
mailing list