On Mon, Mar 22, 2010 at 7:59 PM, Paul E. Jones <[email protected]>wrote:
> John, > > > > Why introduce acct: in OpenID? What benefit does that provide us? > I'm not yet advocating for it, just saying that it's an open question. But I think there is a benefit; see below: > > > My thinking was that the RP would essentially do this: > > > > 1) Prompt the user for his identity > > 2) If it is an http(s) URL, go to step 6 > > 3) If it is an e-mail ID looking thing, try to retrieve the XRD document > for acct:u...@hostname > > 4) Finding a link relation that indicates it is an OpenID ID, go to 6 > (Note, if there is more than one, the RP might want to prompt to ask the > user to select) > > 5) Apparently, nothing worked: report an error to the user > > 6) With the OpenID in hand, go through the normal procedures to > authenticate the user as per the OpenID 2.0 spec > > Note that this means the user would not be logged in as [email protected], but instead as https://www.google.com/profiles/3234234234234234. (Since step 6 doesn't know anything about steps 1-5.) I think this has obvious usability issues. Note that the OP cannot return acct:[email protected] <acct%[email protected]> as the claimed_id because the claimed_id has to be an openid, and under this proposal acct:[email protected] <acct%[email protected]> isn't an OpenID. So the RP _might_ be able to retain both the entered (pre-normalized) identifier and the final claimed_id, and display the former to the user and the user's friends, but it seems complicated and unwieldy. > This keeps OpenID and Webfinger distinct with really no dependency on each > other, except that one would need to advertise his/her OpenID ID via their > webfinger account. > > > > Paul > > > > *From:* John Panzer [mailto:[email protected]] > *Sent:* Monday, March 22, 2010 10:12 PM > *To:* Chris Messina > *Cc:* Paul E. Jones; Dirk Balfanz; [email protected]; > [email protected] > > *Subject:* Re: WebFinger at Google > > > > On Mon, Mar 22, 2010 at 5:56 PM, Chris Messina <[email protected]> > wrote: > > On Mon, Mar 22, 2010 at 5:01 PM, Paul E. Jones <[email protected]> > wrote: > > 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. > > I can go either way here, like I said. Inventing " > http://openid.net/identity"; seems arbitrary, and not tied to existing > practice. That's my biggest concern about it; but it's just a URI which has > no semantic meaning... so it's not a deal breaker for me. I just think it'll > be harder to get people to take it seriously if it doesn't look like > anything else. > > > > You and Chris Messina both raised concerns about the e-mail style: should > RPs remember the email ID or the OpenID value? > > RPs can of course remember what the user first entered into the box, but > unless the OP returns the same identifier as an email address of the user, > it shouldn't be trusted. > > > > I think that would be OK, as long as RPs that start with an acct: URI will > also accept an acct: URI returned from the OP (probably the same one). > > > > It does raise the question of whether, if the user starts with an HTTP: > URI, RPs can be expected to support a claimed ID with scheme acct:. Side > issue. > > > > > > After all, that's the whole thrust of the relationship that's being > created: the *relying party* relies on the *identity provider* for some user > — it doesn't matter what gets entered into the RP's site (they could just as > easily offer a NASCAR array of buttons) — what SHOULD matter to the RP is > what the OP returns after the user has presumably authenticated. > > > > Historically, the problem is that the simple OpenID 1.0 lightweight > delegation model (put a link on your webpage) got effectively broken in 2.0 > because 2.0 OPs started reporting the IDs that they knew about rather than > the one the user was actually claiming. The spec did not help with this. > > > > > > Can we get all OpenID RPs to accept an email form? > > > > Yes. However, we need to specify exactly how this should work and then go > about building support into the OpenID libraries. As it is, you can use an > email-style identifier in OpenID flows (http://[email protected] is a valid > URL) — but it doesn't work reliably or consistently. > > > > It'd going to be horribly inconsistent as many OPs don't even see the > "chris" part of that identifier or pay any attention if they do (today). > Changing to (implicit) acct: solves this. > > > > > > 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. > > Changing OPs is essentially out of scope. It's no different than if a > user changes her email address today. > > > > Sites should build in appropriate account recovery mechanisms as needed, > which may include linking more than one OpenID or email address to a given > account. > > > > We can't force people to manage their online accounts more sensibly, or > build in that level of policy into the protocol (for example, someone's > account might be shut down for abuse — but we can't specify what abuse is, > or what to do about it). > > > > 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? > > > > RPs should allow users to associate multiple identifiers to their account, > especially to aid in account recovery; this practice is up to the RPs to > implement, however. > > > > And, to illustrate this problem more acutely, here is what my WebFinger > address returns: > > > > http://webfinger.org/lookup/[email protected] > > > > I can't imagine an RP asking me which of these accounts I want to use for > signing in... > > > > Chris > > > > > > 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] <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 > > > > > -- > Chris Messina > Open Web Advocate, Google > > Personal: http://factoryjoe.com > Follow me on Buzz: http://buzz.google.com/chrismessina > ...or Twitter: http://twitter.com/chrismessina > > This email is: [ ] shareable [X] ask first [ ] private > > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
