This link has been bookmarked by 22 people . It was first bookmarked on 26 Oct 2007, by Marko Anastasov.
-
28 Oct 09
-
- the user enters their identity URL into a form on the RP
- the RP performs discovery on that URL to find the user’s OP.
- the RP initiates an OpenID authentication request with that OP.
- An OpenID provider can give their users a single URL that will work for everyone. For instance, if AOL sets things up correctly, you’d be able to type “aol.com” into any OpenID 2.0 enabled site to log in with an AIM screen name.
- A privacy concious user could configure their own OpenID provider that will hand out different identity URLs to different RPs, similar to how some people use single-purpose email addresses today.
- If an RP requires that users use a particular OP, they could use directed identity to begin the authentication request without requiring the user to enter an identity URL.
Directed Identity
For OpenID 1.1, the authentication process goes something like this:
With OpenID 2.0, the discovery process may tell the RP that the URL identifies the OP rather than the user. If this happens, the RP proceeds with the authentication request using the special “http://specs.openid.net/auth/2.0/identifier_select” value as the identity URL. The OP will then fill in the user’s actual identity URL in the subsequent authentication response. As an additional step, the RP is then required to perform discovery on this URL to ensure that the OP is entitled to authenticate it.
There are a number of cases where this feature can be useful:
-
- Unlike the simple registration extension, the attribute exchange extension does not have a fixed set of attributes that can be transmitted. Instead it uses URIs to identify the attribute types, making it easy to define new attributes without causing conflicts. Of course an attribute is not particularly useful if no one else supports it, so there is a process set up to standardise common attribute types.
- As well as receiving attribute values as part of an authentication response, an RP can request that an OP store certain attribute values. This is done as part of an authentication request, so the OP can verify that the user really wants to store the values.
- The RP can request ongoing updates for the attributes it is interested in. As an example, if you stored your hackergotchi with your OP, changes to the image could be automatically pushed out to all sites you use that want to display that image.
Attribute Exchange Extension
The OpenID Attribute Exchange extension is like the simple registration extension on steroids. The major differences are:
-
-
08 Apr 08
-
-
- proper extension support
- support for larger requests/responses
- directed identity
- attribute exchange extension
- support for a new naming monopoly
-
-
15 Dec 07
-
08 Dec 07
-
07 Dec 07
-
13 Nov 07
-
29 Oct 07
-
26 Oct 07
-
23 Oct 07
-
Boris MannGood overview of OpenID 2.0 -- I feel the same way about i-names, and can see it getting ripped out in future versions. I didn't know about using the OP url as an identity URL that is *very* interesting
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.