WebFinger at Google

Tue Mar 23 02:50:40 UTC 2010

Chris,

The LRDD document needs something, I think, in order to allow RPs to easily
map e-mail IDs to OpenID IDs. The proposed value is arbitrary, but we need
to put a stake in the ground and get everybody to agree on what that is.

I'm not sure where the list of accounts came from on the webfinger.org page,
but it appears to have been pulled from your Google profile page.  Is that
published in some easy-to-digest document?  Whatever the case, you would
expect any of those URIs to potentially be an OpenID ID?  Would the RP have
to then go fishing to see which are and are not?  As an RP, I think it would
be a lot of overhead.  As the user, I'd be annoyed seeing all of the
options.

So, if the RP can query an account like acct:paulej at packetizer.com, the RP
could find a Link (or more than one, if the user wished) containing the
value of the OpenID ID in the href.  Like this:

   curl http://www.packetizer.com/lrdd/?uri=acct%3Apaulej%40packetizer.com

Anyway, apparently folks had this idea in mind already, since that's how I
discovered the rel value Google was using to apparently refer to one's
OpenID ID.  I also include that in my account document.  I can live with
either the "identity" and "provider" URI types appear, though "identity"
seems more logical to me.

Paul

From: Chris Messina [mailto:chris.messina at gmail.com] 
Sent: Monday, March 22, 2010 8:56 PM
To: Paul E. Jones
Cc: John Panzer; Dirk Balfanz; webfinger at googlegroups.com;
openid-specs at lists.openid.net
Subject: Re: WebFinger at Google

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. 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.

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.

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 <mailto: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 <mailto: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 <mailto: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'?>

<!-- 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.wi
ki?spec=svn22
<http://code.google.com/p/webfinger/source/browse/wiki/CommonLinkRelations.w
iki?spec=svn22&r=22> &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/fc7aefdf/attachment.htm>