[PROPOSAL] Handle "http://user at example.com" Style Identifiers

Peter Watkins peterw at tux.org
Thu Nov 9 00:21:02 UTC 2006


Recordon, David wrote:
> Involving DNS seems to make this too complex.  If we're going to involve
> DNS, we might as well re-architect Yadis to use it as yet another
> discovery option.

Yes, the TXT proposal seems complex. I prefer Phillip's second
suggestion, but I think something more unique would be advisable, e.g.

http://openid.example.com/openid/user

so that organizations can more easily separate the OpenID IdP systems
(hostname openid.MAILDOMAIN, web path /openid/) from any regular
http/https offerings.

It would be nice (see my 'concerns about each user having a unique
"URL"' thread in the general openid list) if this could handle empty
usernames, e.g. if users could claim an identifier like
  @example.com
to identify the IdP but let the IdP determine the user's identifier.

-Peter

> -----Original Message-----
> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
> Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs at openid.net; general at openid.net
> Subject: RE: [PROPOSAL] Handle "http://user@example.com" Style
> Identifiers

> 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.

> What I would suggest is that we resolve user at example.com 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:sappenin at gmail.com]
>> Sent: Wednesday, November 08, 2006 1:56 PM
>> To: Hallam-Baker, Phillip
>> Cc: specs at openid.net; general at openid.net
>> Subject: RE: [PROPOSAL] Handle "http://user@example.com" 
>> 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:pbaker at verisign.com]
>>> Sent: Wednesday, November 08, 2006 1:45 PM
>>> To: David Fuelling; specs at openid.net
>>> Subject: RE: [PROPOSAL] Handle "http://user@example.com" 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:user at example.com or 
>> to define 
>>> openid:user at example.com
>>>
>>>
>>> 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: specs-bounces at openid.net
>>>> [mailto:specs-bounces at openid.net] On Behalf Of David Fuelling
>>>> Sent: Wednesday, November 08, 2006 1:40 PM
>>>> To: specs at openid.net
>>>> Subject: RE: [PROPOSAL] Handle "http://user@example.com"
>>>> Style Identifiers
>>>>
>>>> Please see my questions/ideas enclosed...
>>>>
>>>> Thanks!
>>>>
>>>> David Fuelling
>>>>
>>>>> -----Original Message-----
>>>>> From: specs-bounces at openid.net 
>> [mailto:specs-bounces at openid.net] 
>>>>> On Behalf Of Drummond Reed
>>>>> Sent: Friday, October 20, 2006 1:04 AM
>>>>> To: 'Recordon, David'; specs at openid.net
>>>>> Subject: RE: [PROPOSAL] Handle "http://user@example.com" 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 beth at example.com 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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061108/b78603b8/attachment-0002.pgp>


More information about the specs mailing list