John,
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. You and Chris Messina both raised concerns about the e-mail style: should RPs remember the email ID or the OpenID value? Can we get all OpenID RPs to accept an email form? As for getting consistency: that's very much needed, and I really think this will happen sooner than later. People are comfortable with e-mail style addresses and RPs will want to try to resolve it, I would expect. 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. 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? Paul From: John Panzer [mailto:[email protected]] Sent: Monday, March 22, 2010 4:58 PM To: Dirk Balfanz Cc: Paul E. Jones; [email protected]; [email protected] Subject: Re: WebFinger at Google So the distinction appears to be in the (conceptual) relations between: TODAY: acct:[email protected] <mailto: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] <mailto: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] <mailto: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.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
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
