[OpenID] [LIKELY_SPAM]Re: OpenID SREG best practice question

[Peter Williams]

We do the same thing in US realty, essentially. Using a metadata standard (that has various forms, including csv and xml schema, and could easily dynamically spit out the RP's own XRDS too) each RP subscribes out-of-band to the attribute authority. It's like what SAML would do if its metadata for attribute contracts was more complete (and used). In our metadata, the data model is RDF like - with types and classes. Security Contracts are just oneobject to be searched for, like more typical data on members and listings.

We now have several spokes that upon receiving the SAML post (or would-be openid assertion) then go and pull the membership attribute  relating to the primary key from the attribute authority. We have 1000 spokes who do the equivalent of the  SAML/OpenID using a variety of proprietary handoff techniques, mostly developed over the last 15 years of doing this sort of thing on the web. Some of the techniques are relics of the pre-web versions of the same flow, using authorized dialbacks!

Of course this is just the classical SAML push then pull model. What we did a bit better was allow the RP metadata to be actually published in a repository with a common access method, so it ACTUALLY auto-configures the RP software (once the policy is set, and expressed). Change policy, software adjusts.

The attribute authority is itself often a chaining and aggregation proxy, much like the X.500 directories chaining model. Now that RDF is getting mainstream and works in the core of SQL-server 2008, I can see us making our authorities perform dynamic collation of subordinate attribute authorities, quite soon, at high data rates.

All we really need for openid is some XRDS extensions that describe the attribute contracts.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Nate Klingenstein
Sent: Thursday, November 13, 2008 7:53 AM
To: Ben Laurie
Cc: OpenID General
Subject: [LIKELY_SPAM]Re: [OpenID] OpenID SREG best practice question

Ben,



Clearly as (if?) more attributes get added into the mix more thought

will have to go into this aspect.

We share and utilize a very large number of attributes, and many applications do need much more information than email address.  Some need less.  In our deployments, each service has the ability to express which attributes it needs.  See, for example, this page, and click on "Show requested attributes":

http://www.switch.ch/de/aai/participants/allresources.html?show=all

Then, the IdP administrator can choose to alter these defaults for their local userbase.  This has worked out great for these apps, but it's not a general solution (and doesn't help in your situation regardless).

User-managed release of attributes was a key design tenet for us that has seen very little uptake in the real world.  We've tried interfaces that allowed users to individually select which attributes, building from a default set, they would like to block or enable the release of.

1)  It created a surge in help desk calls as well-meaning users locked themselves out of apps.
2)  Most users didn't care at all, and the ones who did care, didn't care on such fine granularity.

We're now toying with interfaces that are opt-in/opt-out, and ones that can give "levels of service" based on how much information you're willing to reveal, e.g. persistent pseudonym = personalized content.  It gives the user the ability to do consent-based release for many services, and for services that are absolutely necessary to providing an education for the student, they won't be prompted.  We'll see if these are more successful.

Something certainly has to be done, though.  We don't want the IdP administrator to be a gatekeeper for all services.  It works very well for the major apps with our large user bases, but it's not scaling down to the small collaborations.  I suspect this is why Eric is so keen to have some formal research into the problem.

Take care,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081113/0bd51e68/attachment-0002.htm>