John,
Well, I'm not going to argue a bit with you on that point, but I nearly got shot some time ago for daring to suggest that OpenID needs to use something like email IDs. When I inquired more recently and was referred to the work on Webfinger, so I gathered that folks were having a change of heart. And, I think Webfinger is great. I see it as a way of getting the benefit from the existing OpenID spec and growing number of sites that support it, without having to change the existing protocol. I can also think of a lot of other interesting uses for webfinger. There is definitely a benefit to having a separate OpenID identifier, though, as it allows ones email provider and identity provider to be different entities. So, the user ought to be able to specify in the Google profile pages, for example, what his/her OpenID identifier is. That's why I think it's important for the RP to maintain the OpenID identifier internally and why it's best to have this in some form that's human-acceptable form. If designed properly, I think the UI can minimize the complexity and confusion. For the more technically-challenged, they can just enter their email address and "it just works". For those who care to understand a little more, they'll learn that they can specify the identity URI. Before we can do anything, though, we at least need to settle on the link relation value for OpenID URIs published via Webfinger. Is this a job for the OpenID experts with perhaps a new spec published on openid.net, or is this something we should do through the IETF alongside the webfinger document (that does not exist, yet, but I'm sure is coming "soon"). Paul From: John Panzer [mailto:[email protected]] Sent: Tuesday, March 23, 2010 7:20 PM To: Paul E. Jones Cc: Chris Messina; Dirk Balfanz; [email protected]; [email protected] Subject: Re: WebFinger at Google A fundamental premise of Webfinger is that there are a lot of users -- today, probably the majority of the Internet -- who are comfortable with and know their email address (or email like identifier, like a Jabber ID), who have no interest in acquiring an HTTP identifier as well, and in fact an extra HTTP identifier is a hindrance to them using the technology. So, the desire to avoid the HTTP identifier in a user visible context derives from that premise. And a login ID is definitely user visible; it's how you show a user who they're currently logged in as, for example. On Tue, Mar 23, 2010 at 12:39 PM, Paul E. Jones <[email protected]> wrote: John, 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] <mailto:acct%[email protected]> as the claimed_id because the claimed_id has to be an openid, and under this proposal acct:[email protected] <mailto: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. I'm not really sure what to do about the fact that the real OpenID identifier is something nearly impossible to remember. Perhaps one might argue that "that's not the way it's supposed to be." :-) Shouldn't the OpenID ID's - even as HTTP(S) URIs - still be somewhat memorable? That said, does it really matter? If the user always logs in with an email ID that is converted using Webfinger into the real OpenID ID, the process is always the same. I would strongly suggest not trying to hide the OpenID ID or make it hard to remember. Why not https://openid.google.com/bob? That's likely easier to remember. So, is your concern with the user having to potentially remember two IDs, or the fact that one is impossible to remember? :-) Paul
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
