WebFinger at Google

John Panzer jpanzer at google.com
Mon Mar 22 18:42:47 UTC 2010


...and what I mean by this is that rps should not just preprocess and
throw away what the user entered (as with directed identity) but
actually use it, if appropriate, as the user's human readable foreign
Id.  In the same way they treat email addresses today.

And this is because the openid URL you end up with may well be long
and unreadable.

On Monday, March 22, 2010, John Panzer <jpanzer at google.com> wrote:
> 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
>> -->
> --
> --
> John Panzer / Google
> jpanzer at google.com / abstractioneer.org / @jpanzer
>

-- 
--
John Panzer / Google
jpanzer at google.com / abstractioneer.org / @jpanzer


More information about the specs mailing list