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.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 > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
