Thanks, that's useful clarity! I'm much more in the camp of just relying on LRDD (in JSON http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/) and shifting the effort to the server. WebFinger is really just a profile of LRDD.
--David On Sat, May 15, 2010 at 5:36 AM, John Bradley <[email protected]>wrote: > David, > > If I understand Paul correctly he is asking for a two stage resolution. > > Stage 1 Webfinger to get a openID identifier for the person. > Stage 2 Current Yadis resolution on that ID to get the endpoint. > > That is why he prefers claimed ID to remain http: URI. > > This would require 3 or 4 GET to go from input identifier > acct:[email protected]<acct%[email protected]>to a openID endpoint the RP can query. > > It also requires the RP to parse the current XRDS XML and the new XRD XML > with different schema and semantics. > > I think he and some others are looking at this as webfinger being a > separate front end to existing openID 2.0 authentication. > > Paul correct me if I have that wrong. > > John B. > > On 2010-05-15, at 1:16 AM, David Recordon wrote: > > Hey Paul, > That sounds right. I'd really like to see us simplify it though. Ideally > getting to where a RP can make a single HTTP request and end up with the > OpenID endpoint. For example, why not combine steps #3 and #4? > > --David > > > On Thu, May 13, 2010 at 9:00 AM, Paul E. Jones <[email protected]>wrote: > >> 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]<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}<http://www.packetizer.com/lrdd/?uri=%7Buri%7D> >> " >> >> 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] <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] <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]<acct%[email protected]>, >> then when WebFinger is employed, the Subject of the XRD document is >> acct:[email protected] <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] <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 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 >> >> >> >> >> >> >> -- >> 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
