Trust/threat model for OpenID

Recordon, David drecordon at verisign.com
Tue Aug 1 05:22:40 UTC 2006


As we were looking to evolve OpenID Authentication, we saw the need for supporting the use cases of multiple personas directly within an IdP.  With the help of Sxip, we've incorporated this ability within the current Authentication drafts to provide the framework for an IdP/Homesite to allow the user to select which persona they wish to assert or to assert a completely "anonymous" one each time.  We also have the means in place to not move an identifier as part of the response to checkid_setup or checkid_immediate, but rather have the data payload contain the needed information such as an assertion that this user is over 21 for use cases where their actual identity is not needed.

As Dick said, we're looking forward to working with him and his team over the next few weeks as the OpenID Authentication and Data Transport (yes, I know we've promised this to the mailing list already) specs continue to evolve as well as to help him provide rich profile exchange for the OpenID framework.

--David


-----Original Message-----
From: yadis-bounces at lists.danga.com on behalf of Dick Hardt
Sent: Mon 7/31/2006 10:08 PM
To: Johannes Ernst
Cc: OpenID Discussion
Subject: Re: Trust/threat model for OpenID
 
Ben

In our implementations of a Homesite, we let the user select which  
persona they want to be at a new site. One of those is an "anonymous"  
persona that will have a unique URL for each site.

This lets the user decide on a site by site basis what is disclosed.

-- Dick

For those of you reading between the lines, Sxip is working on  
supporting OpenID 2.0 now that providing an IdP is possible.

On 31-Jul-06, at 2:32 PM, Johannes Ernst wrote:

> Drummond is on travel, I think, so I'll take the liberty to respond  
> to this ...
>
> What is and isn't the right default behavior on issues like this is  
> rather hard to determine, unfortunately.
>
> For example, those of us with a background in privacy would argue  
> that the default behavior MUST (as in uppercase-MUST) be separate  
> identifiers per party. In fact, many are arguing that the whole  
> idea of an identifier-based design (URLs, XRIs, any kind of  
> identifier) is very wrong in the first place.
>
> On the other hand, we see dramatic market uptake of services like  
> MySpace that are a correlator's and too-much-personal-information- 
> readily-available dream (as opposed to a privacy advocate's).  
> Closer to home, ClaimID and a number of other services wouldn't be  
> in existence if they hadn't seen a need/desire by a substantial  
> number of people to correlate more, rather than less, of their on- 
> line identity. The first thing you do there is enter all your  
> unique-identifiers-by-party and say they are all correlated.
>
> So I concur with Drummond: it needs to be a policy decision by the  
> implementor. Some will cater to one market, some to the other.  
> Specifications should work either way.
>
> Thanks,
>
>
> Johannes.
>
>
> On Jul 31, 2006, at 13:19, Ben Hyde wrote:
>
>> On Jul 31, 2006, at 1:15 PM, Drummond Reed wrote:
>>> As far as "the default behavior", that's not quite the
>>> right question:
>>
>> I beg to differ :-).
>>
>>> this is a feature that an OpenID IdP/i-broker either
>>> implements or not. If they've implemented it, a user can do  
>>> anonymous login
>>> simply by using the identifier of their IdP/i-broker. So it's up  
>>> to a user
>>> whether they want to be anonymous or not.
>>
>> Right, agreed, assuming somebody demonstrates that it's  
>> implementable.
>>
>> But really, isn't that the wrong design?
>>
>>  - ben
>
> Johannes Ernst
> NetMesh Inc.
>
> <lid.gif>
>  http://netmesh.info/jernst
>
>
>
>






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060731/0b7bf885/attachment.htm


More information about the yadis mailing list