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:[email protected]] Sent: Monday, March 22, 2010 12:02 PM To: Paul E. Jones Cc: [email protected] Subject: Re: WebFinger at Google On Fri, Mar 19, 2010 at 10:17 AM, Paul E. Jones <[email protected]> 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.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 [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
