[+webfinger list] Hi guys,
see below - the question is whether http://specs.openid.net/auth/2.0/provider is the best name for the OpenID in a webfinger XRD. Dirk. On Mon, Mar 22, 2010 at 10:22 AM, Paul E. Jones <[email protected]>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:[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.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
