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

Dick Hardt dick at sxip.com
Mon Oct 23 01:27:24 UTC 2006


On 22-Oct-06, at 2:28 PM, Praveen Alavilli wrote:

>
>
> kaliya at mac.com wrote:
>> For starters please don't use Comic Sans in professional  
>> correspondence. it is very hard to read (or take seriously)   
>> http://bancomicsans.com/home.html
>>
>>
>> On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:
>>>
>>>
>>> It's more of a problem with how we can accept 3rd party OpenId  
>>> users at AOL (we as an RP). Obviously for simple use cases like  
>>> leaving comments on blogs it wouldn't really matter as long as  
>>> the user is identified by someone (and someone doing rate  
>>> limiting or something else to prevent spamming - otherwise I  
>>> still can't see how it reduces spam anyway) - but when we want to  
>>> take it to the next level - provide more services to these users  
>>> (photos/calendar/etc.. ) we want to limit it to only a few IDPs  
>>> whom we trust. (due to both security and business reasons).
>>
>> This doesn't really work in the model.  The goal is to let anyone  
>> set up their own OpenID and that basically across the OpenID  
>> universe it works.  You limiting it to only like verisign or other  
>> 'big' IdP's is not really part of the vision of what we are trying  
>> to build.  Obviously behind this whole network needs to be  
>> reputation for IdPs and individual OpenID addresses.
> I understand it's not the vision of OpenId, but accepting  
> identities from everyone else in the world is not going to happen  
> in "reality".

It will in my "reality" :-)

> Obviously there is no reputation service built by trusted vendors  
> (similar to CAs) yet. We need a short term solution atleast (though  
> we all hate short term solutions) if we really want OpenId to be  
> supported by big players  - isn't it ?
>>
>>> So this is the problem we are trying to figure out how we can  
>>> message the users that we support OpenIds from certain providers  
>>> (say Verisign PIP) but not from all.
>>
>> This is one way to approach it and I hope you don't do it this way  
>> because it breaks what OpenID is about.
> Well, it really depends on what else OpenIds are going to be used  
> for. As I said, if it's just the blogging domain I don't think  
> there are any issues. If we want to start pushing OpenId into a  
> trusted and secure authentication domain (I really think it  
> should), some changes need to happen.  Although "Reputation" is a  
> good solution but unfortunately Reputation for IDPs or user URI's  
> is not going to build over night. It changes the way how web apps  
> and users got used to traditionally. Today as an example, I can  
> goto AOL Personal Finance, create an account, setup my financial  
> accounts, bill pay, etc.. with in few mins.

And they could do the same thing with OpenID. The difference would be  
they would not need to create a password, and could click buttons to  
provide a bunch of the profile data. There really is little  
difference except for the automation.


>>>
>>> Another area where we want some more clarification (if it already  
>>> exists) or support is about how we can have a persistent handler  
>>> (apart from URI) for a given user so it would help in cases when  
>>> a user's account gets reclaimed by someone else.
>>
>> ahh...that is where further reading of what i-names and i-numbers  
>> are about would help.  Because there is another level of  
>> indirection built in, when an i-name is reassigned the i-number  
>> below it is not.   This helps users not have the 'reclaiming by  
>> someone else problem' when depending on URLs.
> Actually there were 2 things I was trying to point on in my  
> previous mail (sorry I was not clear). One is the persistent id,  
> which would probably be satisfied with i-numbers (even though I was  
> looking more for optimization by including it as part of the  
> authentication response itself) and second is the PPID (or LUID or  
> SUID or whatever people refer to them in different protocols/ 
> specs), which is not just an i-number but it's an id that's  
> different for each RP such that users cannot be tracked across  
> different sites.

There are "portable identifiers". URLs that the user controls that  
they can point to whichever IdP they want.

There are also "directed identifiers". URLs generated by the IdP and  
managed by the IdP for each RP. In other words, there is a separate  
identifier for each RP so that RPs cannot correlate data.

-- Dick



More information about the specs mailing list