WebFinger at Google

[John Panzer]

So the distinction appears to be in the (conceptual) relations between:

TODAY:
acct:bob at gmail.com <acct%3Abob at gmail.com> maps with rel=
http://specs.openid.net/auth/2.0/provider to
http://www.google.com/profiles/3922823829347234234

=="My OpenID provider is this OpenID over there" -- this does read weirdly.

PROPOSED:
acct:bob at gmail.com <acct%3Abob at gmail.com> maps with rel=
http://openid.net/identity to
http://www.google.com/profiles/3922823829347234234

=="My OpenID identity is this OpenID over there" -- reads okay, but wouldn't
rel="me" be the same?

REJECTED:
acct:bob at gmail.com <acct%3Abob at gmail.com> maps with rel=
http://specs.openid.auth/2.0/server
to http://www.google.com/profiles/3922823829347234234

=="My OpenID provider server is this URL over there" -- would make sense if
you say that an acct: URI _is_ an OpenID.

Seems to me that the last one would make sense iff an acct: URI could be
considered an OpenID in and of itself, and not otherwise.  And the middle
one could make sense in that scenario, but would be a bit indirect and
unnecessary.

Thus, my questions :)

I'm purposely using the ugly default Google profile URLs to make a point, of
course.



On Mon, Mar 22, 2010 at 9:01 AM, Dirk Balfanz <balfanz at google.com> wrote:

>
>
> 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'>gmail.com</hm:Host>
>>
>>   <Link rel='lrdd'
>>
>>         template='http://www.google.com/s2/webfinger/?q={uri}<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:<user>@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/<user>'/>
>>
>>
>>
>> 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/CommonLinkRelations.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, which is what I configured my
>> server to return.
>>
>
> "signon" points to the actual OpenID endpoint (the URL that RPs send their
> association requests to, that they redirect the users to, etc.) The claimed
> id for which signon identifies the OpenID endpoint is the URI on which
> discovery is performed. So "signon" wouldn't work for two reasons:
>
> (1) http://www.google.com/profiles/<user> is not Google's OpenID endpoint
> (2) acct:<user>@gmail.com (which is what you're performing discovery on)
> is not a valid OpenID
>
> http://www.google.com/profiles/<user> is, in fact, the user's OpenID (aka
> "claimed id", but as I mentioned, _not_ Google's OpenID endpoint). The
> OpenID 2.0 spec doesn't specify a link relation that means "this is my
> OpenID", so that's what the "provider" link relation is supposed to convey.
> It's not part of any standard (since webfinger itself hasn't been formalized
> yet).
>
> Does this make sense?
>
> In a related note, I _would_ like to be able to put "signon" links in
> webfinger XRDs, and make OpenID handle acct:URI (which it necessarily would
> have to, at that point), but that won't happen until we have a new version
> of OpenID.
>
> Dirk.
>
>
>  I made that assumption based on looking at all of the XRDS examples in the
>> OpenID 2.0 spec.
>>
>>
>>
>> Paul
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100322/b7da4cef/attachment.htm>