Eran,
I would suggest not using "provider", since the mapping does not point to the provider. Rather, the href in the <Link> is the OpenID identifier for the user. So, perhaps the relation might simply be "openid". Anyway, I have no objection at all to what this value ought to be, but we need to reach some agreement somehow. I have a particular preference for URIs as values for relations, simply because it does not require formal registration with the IETF. (Agree, it's not a big deal, but what's the benefit?) Paul From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: Monday, March 22, 2010 9:08 PM To: [email protected] Subject: Re: WebFinger at Google LRDD uses XRD which uses Web Linking. In Web Linking, if you have a well-defined relation type, you should make it a registered short name. Registration is pretty easy (a spec, which can be an OpenID Foundation document, and RFC, etc.). So... 'openid.provider' is much more suitable. OpenID 2.0 didn't have a discovery layer on the server side so it had to encode the version in the relation type. This is a mistake. The relation is not versioned, just the provider's endpoint (which can be described in its own XRD - that's the correct architecture). So I would use something as short and simple as 'openid.provider'. You can start using it now in XRD documents (or elsewhere included in LRDD). You can worry about registration later once OpenID officially uses LRDD in a spec. If you don't want to overlap with previous values, you can make up a new one like 'openid.server' (I never liked the provider and relaying party terminology). We worked hard on the Web Linking spec so that you don't need to continue using these URI relation types... EHL On 3/22/10 5:22 PM, "Paul Jones" <[email protected]> wrote: Eran, That's what we're shooting for. Assuming we're using LRDD, what "rel" value should one look for in an LRDD XRD document to map a user with a given acct: URI to an OpenID URI. The LRDD document returned for a given acct: URI might contain a <Link> like this: <Link rel='http://openid.net/identity' href='http://openid.packetizer.com/paulej'/> Is that what you're thinking, or did you have something else in mind? Paul From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: Monday, March 22, 2010 4:17 PM To: [email protected]; John Panzer Cc: Dirk Balfanz; [email protected] Subject: Re: WebFinger at Google OpenID should just use LRDD which works for http/https/acct URIs. WebFinger is really just a subset of LRDD. EHL On 3/22/10 11:52 AM, "Paul Jones" <[email protected]> wrote: John, I'd assume RPs will know how to do webfinger, but I don't think we need to tightly bind the OpenID and webfinger specs. Can we assume that if a user enters [email protected] that the RP might formulate an acct: URI type and then perform a query for acct:[email protected]? I think that's a reasonable assumption, since that's likely going to be the natural way people would expect it to work. The real question is: what should it be looking for in the XRD document returned for an acct: URI? What I'm suggesting is this: <Link rel='http://openid.net/identity' href='http://openid.packetizer.com/paulej'/> What Google is presently returning is this: <Link rel='http://specs.openid.net/auth/2.0/provider' href='http://openid.packetizer.com/paulej'/> I suppose it's six of one or half a dozen of another. However, the latter seems to suggest it's not the user's identity URL, but rather a pointer to the provider. But, I think the intent is return the user's OpenID ID in that href, right? So, what value should we use for the link relation? Paul > -----Original Message----- > From: John Panzer [mailto:[email protected]] > Sent: Monday, March 22, 2010 2:28 PM > To: Paul E. Jones > Cc: Dirk Balfanz; [email protected] > Subject: Re: WebFinger at Google > > Assuming you want to use the ID the user entered, I think openid rps > would need to know about acct: at least. > > On Monday, March 22, 2010, Paul E. Jones <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dirk, > > > > > > > > Thanks for the clarification. I now understand the reasoning. > > > > > > > > I would not want to require the OpenID spec to handle acct: URI > > types, per se, but it would be nice if the OpenID RPs would pre- > process whatever > > the user enters and use webfinger to determine the OpenID ID if > whatever is > > entered looks like an email address. Do we need to change the OpenID > spec > > to make that happen? I think these steps could be independent. > > > > > > > > You've certainly made a valid point for why this ought not > > be the "signon" URI. But, is "provider" the right > > word? What I really want is to simply map the thing that looks like > an > > email address into the OpenID ID. > > > > > > > > How about this: http://openid.net/identity > > > > > > > > This would refer to the "claimed ID" (if that's > > not too confusing with openid.identity). > > > > > > > > I removed all of the version information, since I assume my > > OpenID ID would never change from one version of OpenID to another. > If it > > did, users would have never-ending frustration with identifiers. So, > I > > think we can assume this will be fixed. > > > > > > > > So, the XRD document might contain: > > > > > > > > <Link rel='http://openid.net/identity' > href='http://openid.packetizer.com/paulej' > > /> > > > > > > > > I think this is basically the same thing as using "provider", > > but I think it is clearer that it's not the OpenID provider / server > / > > whatever, but merely the user's OpenID ID. Once this transformation > > is made, then the normal OpenID RP procedures would be followed to > find the OP > > Endpoint URL, as you explained below. > > > > > > > > In any case, I guess it does not make a lot of difference > > whether we use: > > > > http://openid.net/identity > > > > or > > > > http://specs.openid.net/auth/2.0/provider > > > > > > > > But, given this ought to be a constant mapping (acct: URIs to > > OpenID identity URIs), I prefer the former. > > > > > > > > Whatever the case, how can we settle on this and set it on stone? > > I think getting agreement quickly is more important than the > particular value. > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > > From: Dirk Balfanz > > [mailto:[email protected]] > > Sent: Monday, March 22, 2010 12:02 PM > > To: Paul E. Jones > > Cc: [email protected] > > Subject: Re: WebFinger at Google > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 19, 2010 at 10:17 AM, Paul E. Jones > <[email protected]> wrote: > > > > > > > > > > > > Folks, > > > > > > > > Google > > appears to have Webfinger enabled on some accounts, at least. You > can see > > it with this: > > > > curl > > http://gmail.com/.well-known/host-meta > > > > > > > > That > > returns this: > > > > > > > > <?xml version='1.0' > > encoding='UTF-8'?> > > > > <!-- NOTE: this host-meta > > end-point is a pre-alpha work in progress. Don't rely on it. --> > > > > <!-- Please follow the > > list at http://groups.google.com/group/webfinger > > --> > > > > <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0' > > > > > > > > xmlns:hm='http://host-meta.net/xrd/1.0'> > > > > <hm:Host xmlns='http://host-meta.net/xrd/1.0' <http://host-meta.net/xrd/1.0'%3egmail.com%3c/hm:Host> >gmail.com</hm:Host <http://host-meta.net/xrd/1.0'%3egmail.com%3c/hm:Host> > > > > > <Link rel='lrdd' > > > > > > template='http://www.google.com/s2/webfinger/?q={uri} <http://www.google.com/s2/webfinger/?q=%7buri%7d> ' <http://www.google.com/s2/webfinger/?q=%7buri%7d'> > > > > > > > <Title>Resource Descriptor</Title> > > > > </Link> > > > > </XRD> > > > > > > > > Now, > > querying the LRDD URL like this: > > > > curl > > http://www.google.com/s2/webfinger/?q=acct: <http://www.google.com/s2/webfinger/?q=acct:%[email protected]> <user>@gmail.com <http://www.google.com/s2/webfinger/?q=acct:%[email protected]> > > > > > > > > will > > return an XRD document, one of whose members is this: > > > > <Link > > rel='http://specs.openid.net/auth/2.0/provider' > > href='http://www.google.com/profiles/ <http://www.google.com/profiles/%3cuser%3e'/> <user>'/ <http://www.google.com/profiles/%3cuser%3e'/> > > > > > > > > > The > > href value might vary, but that's what it returned for my account. > > What concerns me is the link relation value: > http://specs.openid.net/auth/2.0/provider > > > > > > > > Where > > did that come from? The 2.0 spec defined two possible values: > > > > http://specs.openid.net/auth/2.0/server > > > > http://specs.openid.net/auth/2.0/signon > > > > > > > > However, > > I cannot find the one Google is using defined anywhere, though I did > see it > > referenced here: > > > > > http://code.google.com/p/webfinger/source/browse/wiki/CommonLinkRelatio > ns.wiki?spec=svn22&r=22 > > > > > > > > Is > > this an error? If not, can somebody point me to the correct > > documentation? > > > > > > > > If > > it is an error, what should the value be? > > > > > > > > I > > had assumed that the most logical choice was > <http://specs.openid.net/auth/2.0/signon> > > > > > > > > > > > > > > > > -- > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > To unsubscribe from this group, send email to webfinger+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. To unsubscribe from this group, send email to webfinger+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. To unsubscribe from this group, send email to webfinger+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. To unsubscribe from this group, send email to webfinger+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
