Drummond Reed responds to my point of OpenID confusion kindly and informatively. It sounds like inputting the IdP’s address is precisely what the new draft does allow, along with having the user pick an identifier:
starting with OpenID Authentication 2.0, a user will have two options for logging into an OpenID-enabled site: with their personal identifier, or with the identifier of their OpenID provider (IdP). If the user chooses the latter option, the IdP will let the user choose the identifier they want to share with the site — anything from a specific persona to a one-time URL/XRI generated by the IdP just for this relationship.
This is an interesting way of going about things, no doubt driven by the essential notion in this system of a URL-based identifier that represents your digital identity. URLs are, of course, not only strings but also nominally communication endpoints, so if the user doesn’t know their URL, I guess it would defeat the purpose because they couldn’t give it out to people or services for use by them. Oh wait, if you share a “specific persona” I guess that means you are happy sharing one of your usual identifiers (in which case, couldn’t you have put that into the login field in the first place, saving a cycle), and then it’s not actually a pseudonym? And a one-time generated URL is a kind of a pseudonym, so you’re effectively saying you want to limit this relationship to just this small IdP/SP “circle”? So maybe that latter step is akin to SAML’s expectation that many scenarios will require user consent to the federation, though the notion of the URL/XRI also being a communications endpoint seems to go unused.
SAML’s use case for privacy-sensitive federation depends on an IdP and an SP being able to forge a unique triple that includes a pseudonym for the user, but the user doesn’t pick it or know it or share it, and of course SAML lets identifiers be in any format, including email addresses, plain strings, etc. (Particular deployments narrow that choice way down, of course.) Here’s SAML’s assumption about federation and its privacy requirements. This is a use case diagram taken from the latest draft of the SAML V2.0 Technical Overview; if it looks squished, click to enlarge:
This use case drives several different flow/pseudonym options, but a fairly vanilla approach is to (a) use a persistent pseudonym so that the relationship between the providers in serving the user lasts beyond a single session (vs. a transient pseudonym that lasts only for the session) and (b) ask the user in real-time for consent to the relationship (enterprise federation might not do this step since they can rely employer/employee relationship policy and contracts for this). Here’s how the flow for this might look; note that it doesn’t label the types of transport bindings used, but typically it’s HTTP redirect or POST:
I think Drummond and I are duty-bound to hang out in a coffee shop sometime soon and figure out all the common touchpoints between OpenID and SAML, because at the very least it will save some Babel-like confusion!
[UPDATED to fix extra space in diagrams. Also note that I’m in the middle of changing the sample provider URLs used in the Technical Overview, so if you check it out, you’ll notice some inconsistency there. To be fixed soon! I’m thinking of using cars.example.ca in honor of Paul…]
1 Response
[…] I last tackled this topic under the name Pseudonym picking, where I tried to do a compare/contrast between OpenID and SAML on this point based on what I was learning from Drummond. Unfortunately, I did an extraordinarily confused job of it. Reading it again, even I don’t understand it, which is pretty bad. But since I ended up giving it another try in the mail thread, I thought I’d share some of that here in case it’s useful. So consider this a sort of V2.0. […]