So the distinction appears to be in the (conceptual) relations between: TODAY: acct:[email protected] <acct%[email protected]> 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:[email protected] <acct%[email protected]> 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:[email protected] <acct%[email protected]> 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 <[email protected]> wrote: > > > 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 > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
