WebFinger at Google

Tue Mar 23 03:03:37 UTC 2010

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: webfinger at googlegroups.com [mailto:webfinger at googlegroups.com] On
Behalf Of Eran Hammer-Lahav
Sent: Monday, March 22, 2010 9:08 PM
To: webfinger at googlegroups.com
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" <paulej at packetizer.com> 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: webfinger at googlegroups.com [mailto:webfinger at googlegroups.com] On
Behalf Of Eran Hammer-Lahav
Sent: Monday, March 22, 2010 4:17 PM
To: webfinger at googlegroups.com; John Panzer
Cc: Dirk Balfanz; openid-specs at lists.openid.net
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" <paulej at packetizer.com> 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 paulej at packetizer.com that the RP might
formulate an acct: URI type and then perform a query for
acct:paulej at packetizer.com?  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:jpanzer at google.com]
> Sent: Monday, March 22, 2010 2:28 PM
> To: Paul E. Jones
> Cc: Dirk Balfanz; openid-specs at lists.openid.net
> 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 <paulej at packetizer.com> 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:balfanz at google.com]
> > Sent: Monday, March 22, 2010 12:02 PM
> > To: Paul E. Jones
> > Cc: openid-specs at lists.openid.net
> > Subject: Re: WebFinger at Google
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 19, 2010 at 10:17 AM, Paul E. Jones
> <paulej at packetizer.com> 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:%3cuser%3e@gmail.com>
<user>@gmail.com
<http://www.google.com/s2/webfinger/?q=acct:%3cuser%3e@gmail.com> 
> >
> >
> >
> > 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
> jpanzer at google.com / 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100322/253eeb2c/attachment.htm>