WebFinger at Google

John Panzer jpanzer at google.com
Tue Mar 23 02:12:03 UTC 2010


On Mon, Mar 22, 2010 at 5:56 PM, Chris Messina <chris.messina at gmail.com>wrote:

> On Mon, Mar 22, 2010 at 5:01 PM, Paul E. Jones <paulej at packetizer.com>wrote:
>
>>  I would vote for the proposed rel value.  One could use “me”, but the
>> whole webfinger acct: XRD document is about “me”.  So, I think we need
>> something specific for OpenID.
>>
> I can go either way here, like I said. Inventing "
> http://openid.net/identity" seems arbitrary, and not tied to existing
> practice. That's my biggest concern about it; but it's just a URI which has
> no semantic meaning... so it's not a deal breaker for me. I just think it'll
> be harder to get people to take it seriously if it doesn't look like
> anything else.
>
>>
>>
>> You and Chris Messina both raised concerns about the e-mail style: should
>> RPs remember the email ID or the OpenID value?
>>
> RPs can of course remember what the user first entered into the box, but
> unless the OP returns the same identifier as an email address of the user,
> it shouldn't be trusted.
>

I think that would be OK, as long as RPs that start with an acct: URI will
also accept an acct: URI returned from the OP (probably the same one).

It does raise the question of whether, if the user starts with an HTTP: URI,
RPs can be expected to support a claimed ID with scheme acct:.  Side issue.



> After all, that's the whole thrust of the relationship that's being
> created: the *relying party* relies on the *identity provider* for some user
> — it doesn't matter what gets entered into the RP's site (they could just as
> easily offer a NASCAR array of buttons) — what SHOULD matter to the RP is
> what the OP returns after the user has presumably authenticated.
>

Historically, the problem is that the simple OpenID 1.0 lightweight
delegation model (put a link on your webpage) got effectively broken in 2.0
because 2.0 OPs started reporting the IDs that they knew about rather than
the one the user was actually claiming.  The spec did not help with this.


>
>
>> Can we get all OpenID RPs to accept an email form?
>>
>
> Yes. However, we need to specify exactly how this should work and then go
> about building support into the OpenID libraries. As it is, you can use an
> email-style identifier in OpenID flows (http://chris@yahoo.com is a valid
> URL) — but it doesn't work reliably or consistently.
>

It'd going to be horribly inconsistent as many OPs don't even see the
"chris" part of that identifier or pay any attention if they do (today).
 Changing to (implicit) acct: solves this.


>
>
>>  What concerns me, though, is maintaining one value vs. the other.  We *should
>> expect* the RPs to remember only the OpenID identifier, since that is the
>> identifier used by OpenID.  The email form is merely used to map to the
>> OpenID identifier.  What happens when a user changes his OP?  If the email
>> form is maintained, then the user could still be able to log in.  However,
>> if only the OpenID ID is stored, the user would need to update that
>> somehow.  But, this is not really a webfinger issue, but a “managing OpenID
>> identities” problem.  Still, if users get used to entering email IDs, then
>> it might become an issue for Webfinger.
>>
> Changing OPs is essentially out of scope. It's no different than if a user
> changes her email address today.
>
> Sites should build in appropriate account recovery mechanisms as needed,
> which may include linking more than one OpenID or email address to a given
> account.
>
> We can't force people to manage their online accounts more sensibly, or
> build in that level of policy into the protocol (for example, someone's
> account might be shut down for abuse — but we can't specify what abuse is,
> or what to do about it).
>
>>
>>
>> Do we allow more than one OpenID for a user acct:?  I prefer to have a 1:1
>> mapping, otherwise it only delays logging in.  It would force OPs to ask
>> which of several identities a user would like to use.  Perhaps there are
>> arguments for allowing more than one?  Would we use a <properties> element
>> to indicate a priority or indicate which ID is active or inactive?
>>
>
> RPs should allow users to associate multiple identifiers to their account,
> especially to aid in account recovery; this practice is up to the RPs to
> implement, however.
>
> And, to illustrate this problem more acutely, here is what my WebFinger
> address returns:
>
> http://webfinger.org/lookup/chris.messina@gmail.com
>
> I can't imagine an RP asking me which of these accounts I want to use for
> signing in...
>
> Chris
>
>
>>
>>
>> Paul
>>
>>
>>
>> *From:* John Panzer [mailto:jpanzer at google.com]
>> *Sent:* Monday, March 22, 2010 4:58 PM
>> *To:* Dirk Balfanz
>> *Cc:* Paul E. Jones; openid-specs at lists.openid.net;
>> webfinger at googlegroups.com
>>
>> *Subject:* Re: WebFinger at Google
>>
>>
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
> --
> Chris Messina
> Open Web Advocate, Google
>
> Personal: http://factoryjoe.com
> Follow me on Buzz: http://buzz.google.com/chrismessina
> ...or Twitter: http://twitter.com/chrismessina
>
> This email is:   [ ] shareable    [X] ask first   [ ] private
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100322/6960f95c/attachment.htm>


More information about the specs mailing list