John,
Perhaps we need to walk through this so that I don't get confused. I had assumed it would work this way: 1) I enter [email protected] into the RP's login window 2) The RP would assume this is acct:[email protected] 3) The RP would query http://www.packetizer.com/.well-known/host-meta to get an XRD document that contains an lrdd link relation with, for example, an href="http://www.packetizer.com/lrdd/?uri={uri}"; 4) The RP would then query the LRDD link with the acct: URI 5) The would return another XRD document with a <Subject> of acct:[email protected], and a <Link> with a link relation value of "openid" (or whatever the group wants to define) 6) The href associated with the above <Link> would be the user's claimed ID. At this point, the RP has an OpenID claimed ID, just as if the user had entered that value into the current OpenID login box to begin with. BTW, all of this is functioning on my site now if you want to actually issue queries to see the results. It's not being used for anything right now, but I implemented it just for the heck of it :-) So, if you're suggesting the mapping from [email protected] to claimed ID would work differently, what steps are you proposing to be taken? Paul From: John Bradley [mailto:[email protected]] Sent: Thursday, May 13, 2010 11:25 AM To: Paul E. Jones Cc: 'Santosh Rajan'; [email protected] Subject: Re: OpenID V.Next - Some Views to Consider The openID link relation is to your openID service eg Google not your claimed_id. The <Subject> of the XRD is the name of the thing you are looking up. If you input [email protected] into a LRDD resolution process and use webfinger for normalization you will get a XRD. That XRD may have the <Subject> http://openid.packetizer.com/paulej That would be up to you or your OP to decide. I think Santosh wants to allow you the option of having acct:[email protected] as the subject of the XRD. This leads to questions about what the core protocol is validating. Is it the claimed_id or the openid.identity. Do we need both, is delegation supported, and if so how, etc. I think the WG needs to consider what impact having non http/https URI as claimed ID has on the overall protocol. I don't want to restrict the WG from considering the issue via the charter. John B. On 2010-05-13, at 10:51 AM, Paul E. Jones wrote: Santosh, The subject of [email protected] is what? If that can be assumed to be acct:[email protected], then when WebFinger is employed, the Subject of the XRD document is acct:[email protected]. That's not what I want. Inside the XRD document should be a link like this: <Link rel="openid" href="http://openid.packetizer.com/paulej"/> The link relation value is still subject to debate, but that's what I think we should use to identify the claimed ID. Paul From: [email protected] [mailto:[email protected]] On Behalf Of Santosh Rajan Sent: Thursday, May 13, 2010 1:50 AM To: John Bradley Cc: [email protected] Subject: Re: OpenID V.Next - Some Views to Consider I will vote for the Subject of the XRD to be the claimed_id. It only seems natural, and clean to do that. On Thu, May 13, 2010 at 3:17 AM, John Bradley <[email protected]> wrote: 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. 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] <mailto: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 URIhttp://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 <http://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 <http://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 -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
