The question is more around how you determine the claimed ID rather than it's form.
Currently in openID 2.0 we have two flows. One where the claimed_id sent to the OP is based on the normalized input identifier, and another where the Subject ( formerly known as CannonicalID) is sent as the claimed_id in the request. The OP has the ability to return any discoverable URI as the claimed_id. In general the OP doesn't change the claimed_id that it returns, except for adding a generational fragment for account recycling. However some do, Yahoo and others will ignore the requested claimed_id and do directed identity returning a different claimed_id in some flows. I think if we say the claimed_id needs to be a discoverable URI, that allows people to continue to use there current claimed_id or an acct: URI as determined by the OP. The question of using the Subject from the XRD is slightly separate. It potentially allows greater user control, by having multiple identifiers resolve to the same claimed_id. This may or may not be the desired behaviour. The other thing to consider is that while openID and perhaps a WebFinger tool may understand non http URI other things like web browsers will not. The notion that you can place the openID in a blog comment and have someone click on it to get to the commenter's blog or info page will fade further into the past. I think that with the major sites not providing web viewable landing pages for the majority of openID, the horse has left the barn on that one already. John B. On 2010-05-13, at 10:47 AM, Paul E. Jones wrote: > John, > > I believe the claimed ID should be the same URI as is used today. That is, > an email address should be mapped via WebFinger into an the claimed ID. > Reasons: > 1) This helps to ensure backward-compatibility > 2) The claimed ID can be easily discovered via WebFinger > 3) The URI would not have to be entered directly by the user to login if > we use WebFinger > 4) We do not lose any security benefits of the current OpenID spec, > since authentication would still be against the existing OpenID URI > > Paul > > From: [email protected] > [mailto:[email protected]] On Behalf Of John Bradley > Sent: Wednesday, May 12, 2010 5:48 PM > To: Santosh Rajan > Cc: [email protected] > Subject: Re: OpenID V.Next - Some Views to Consider > > Webfinger is a profile of LRDD that allows this new thing called an account > URI (We shall make the assumption for the moment that it gets registered and > is a URI) to be resolved via LRDD to a XRD. > > The important thing WebFinger provides is a way to determine the root of > authority for a Acct URI. (The host to start discovery on) > > In principal any URI with a host segment can use LRDD to get a XRD. > > I suppose other types of URI could define some other root for discovery as > well. > > So if openID supports LRDD then normalization rules for Acct: and other URI > schemes could be specified so that they to can be resolved to a XRD. > > The question will be for the core protocol what to use as the claimed_id. > > There are three schools of thought. > 1 The normalized input identifier > 2 The Subject of the XRD > 3 The claimed_id that the OP returns. > > There are arguments to be made for all three. > > I expect this to be addressed in the WG. > > John B. > On 2010-05-12, at 12:34 PM, Santosh Rajan wrote: > > > Starting a new thread here based on an earlier one quoted below. > > Let us reconsider the definition of OpenID for V.next. I would like to see a > new definition for OpenID. > > "An OpenID is Any Valid URI that can be resolved to it's Descriptor". > > Now let me give a little explanation on the above, with a few points. > 1) Existing OpenID's version 1 and 2 are compatible with the above > definition. (http(s) OpenId's version 1 and 2 do resolve to their > descriptor's) > 2) Email like identifiers are compatible with the above definition with the > webfinger protocol, and ofcourse resolve to their descriptor's. > > Now any other future protocol that can make its URI resolvable to a > descriptor, will also be a Valid OpenID. Let me give an example. > > According to the above definition we can make "tag URI's" valid OpenID's, as > long as we have a protocol to resolve this URI to its's descriptor. > tag:[email protected],2007-11-02:Tag_URI > > Now as far as I am concerned tag URI's are even better as OpenID's, because > they are unique over space and time. > > Webfinger support for tag URI's anyone? :-) > > ---------- Forwarded message ---------- > From: Paul E. Jones <[email protected]> > Date: Wed, May 12, 2010 at 8:11 AM > Subject: RE: Draft charter for v.Next Attributes working group > To: Santosh Rajan <[email protected]> > Cc: Mike Jones <[email protected]>, [email protected], > [email protected], [email protected] > > > Santosh, > > Why not store the claimed ID in the webfinger (LRDD) XRD document? > > The objective, I would hope, is to make it easier to log into web sites. > Email-style identifiers make that easier, but the system does not have to be > built around those. > > So, I sign up with a service provider. Let’s just use my own site as an > example. I am assigned an email address [email protected]. Behind the > scenes, I am also assign an OpenID ID http://openid.packetizer.com/paulej. > Now, when I visit a web site, I can type ‘[email protected]’ and the site > can perform a webfinger query to discovery by OpenID ID. We would define a > link relation (something we’ve talked about before) that represents openid. > It could be http://openid.net/identity or it could be simply “openid” (since > link relations need not be URIs). Looking at the href of the “openid” link > relation, one would find my OpenID URI http://openid.packetizer.com/paulej. > > Now, should I wish to have a different email provider than my openid > provider, that’s fine: I could change the record associated with the openid > link relation to contain a different OpenID identifier. Alternatively, I > could just get an account at someopenidop.com and they might assign an e-mail > style address like [email protected] and perform the Webfinger > resolution behind the scenes. > > Anyway, issue this request: > $ curl http://www.packetizer.com/lrdd/?uri=acct:[email protected] > > You’ll see the link relation for my claimed ID: > <Link rel="http://openid.net/identity"; > href="http://openid.packetizer.com/paulej"/> > > It does introduce another protocol, but I think these play nicely together. > The real identity would remain the URL that OpenID uses today. The email > identifier would just be an alias for it. > > Paul > > From: Santosh Rajan [mailto:[email protected]] > Sent: Tuesday, May 11, 2010 12:39 PM > To: Paul E. Jones > Cc: Mike Jones; [email protected]; [email protected]; > [email protected] > Subject: Re: Draft charter for v.Next Attributes working group > > > On Tue, May 11, 2010 at 8:55 AM, Paul E. Jones <[email protected]> wrote: > > Adding support for email-style addresses is something I like, but something > that can be provided via webfinger. Thus, no change to the base protocol. > > > I beg to disagree here. I think the base protocol needs to address the issue > of email like identifiers. I would like to see that email like identifiers > are valid OpenID claimed id's. > So something like acct:example @ example.com should be a valid OpenID > claimed_id. > > Also this discussion should not be in this thread (about attributes) and > maybe someone could start a new thread on this subject. > > Thanks > Santosh > > > http://hi.im/santosh > > > > > -- > http://hi.im/santosh > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
