Please don't map to Http this way. It would be fine to define a fixed mapping from a user identifier to http. But it has to respect the http scheme design and be crafted to avoid operability concerns.
http://example.com/user would be acceptable as meeting the scheme design. It is absolutely critical to maintain left/right hierarchy. The username/password pieces in http were not well thought out and may have to be eliminated. The scheme I would propose would incorporate a policy lookup so that it is possible to overide this mapping. The mapping to http is fine as a last resort but making it the first resort means we cannot ever change it. What I would suggest is that we resolve [EMAIL PROTECTED] as follows 1) Perform a DNS lookup for a TXT record at _openid.example.com if found perform policy processing 2) map the uri to http://example.com/user, do OpenID Policy processing: The TXT record consists of a sequence of tag=value pairs that list the authentication protocols that are supported. This allows the relying party to choose the most appropriate protocol for its needs. For example: "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID" This says that the identity provider supports three different authentication protocols, SAML, a reduced SAML and OPENID. > -----Original Message----- > From: David Fuelling [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:56 PM > To: Hallam-Baker, Phillip > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > Style Identifiers > > Hi Philip, > > I'm not sure I understand "Please don't use HTTP this way". > > I was suggesting that the user enter an email address. The > RP then maps the email address to a URL (which would be in > the proper scheme). > > > > -----Original Message----- > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 08, 2006 1:45 PM > > To: David Fuelling; specs@openid.net > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > > Identifiers > > > > Please don't use HTTP this way. That is not the semantics > for http URLs. > > > > A better scheme would be to use mailto:[EMAIL PROTECTED] or > to define > > openid:[EMAIL PROTECTED] > > > > > > There are two issues here: > > > > 1) The user presentation of the identifier > > 2) The machine presentation > > > > The two do not need to be the same. www.cnn.com works > perfectly well > > as a way to locate CNN. That is a perfectly acceptable user > > presentation. It is not an acceptable machine presentation and > > browsers SHOULD NOT accept href="www.cnn.com". > > > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling > > > Sent: Wednesday, November 08, 2006 1:40 PM > > > To: specs@openid.net > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" > > > Style Identifiers > > > > > > Please see my questions/ideas enclosed... > > > > > > Thanks! > > > > > > David Fuelling > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > > > On Behalf Of Drummond Reed > > > > Sent: Friday, October 20, 2006 1:04 AM > > > > To: 'Recordon, David'; specs@openid.net > > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style > > > > Identifiers > > > > > > > > There have been several long threads in the past about > using email > > > > addresses as OpenID identifiers. The conclusion each time > > > has been to > > > avoid it. I don't remember all the arguments, but among them are: > > > > > > > > * Privacy: the last thing many users want to give a website > > > is their > > > > email address. > > > > > > This seems reasonable at first glance. However, almost every > > > website I have a login with (today) requests my email address so > > > that the site can communicate with me electronically. > > > > > > So, if email addresses WERE used as an additional "login > input" for > > > OpenId, a user who didn't want to use his/her email > address to login > > > could always just use an IdP URL or XRI instead (as they > can today). > > > > > > Am I missing the privacy concern here? > > > > > > > * Reassignability: email addresses are not only > > > reassignable, but for > > > > some domains, they are notoriously short-lived identifiers. > > > > > > Is this really such a problem? It seems to exist for > URL's in the > > > current protocol proposal anyway. For instance, most > people don't > > > own a Domain, which means they'll be using OpenID URL's that > > > somebody else owns. Thus, URL's are reassignable too, and suffer > > > from this in the same way (although I don't really see this as a > > > problem). > > > > > > > * Non-portability: unless you own the top-level domain, they > > > > aren't portable. > > > > > > Again, is this a problem if the email isn't the actual > identifier? > > > If we have a means of mapping an email to an OpenID Identity URL, > > > then if the email goes away (is transferred or otherwise > not in the > > > control of the original user), then what's the problem? > > > > > > Point 1.) Losing an email address is no different than the case > > > where a URL is lost/transferred/goes away. > > > > > > Point 2.) If a user "lost" his email address, theoretically the > > > owner of the email address (example.com, e.g.) would remove the > > > mapping from [EMAIL PROTECTED] to beth's Identity Provider URL. > > > > > > Point 3.) Even if the email address domain owner failed to remove > > > this mapping, only the end-user (beth in this case) would > be using > > > the email to login. Presumably, if she switched email addresses, > > > she would use her new address to login, and it wouldn't matter. > > > Somebody else trying to use her email address would need > to login to > > > the IdP, and presumably be stopped there. > > > > > > > Food for thought... > > > > > > > > =Drummond > > > > > > > > > _______________________________________________ > > > specs mailing list > > > specs@openid.net > > > http://openid.net/mailman/listinfo/specs > > > > > > > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
