[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