OpenID, YADIS and Directed Identity

[Fen Labalme]

Granqvist, Hans wrote:
> Hi Fen, 
> 
> Do you have the cryptographic proof (it's missing 
> from the paper)?

All I have to back it up is some scribbles that I took a photo of here:

	http://pix.fen.net/OpenPrivacy/2000-2001/20010307-stefan/

Not a proof, unfortunately, but I believe one could be derived.

It's an issue I have been working on for many years and finally cornered
Stefan Brand and Ian Goldberg (at the 2001 Computers, Freedom & Privacy
conference in Washington, D.C.) to get them to see if I was nuts or if it
could be accomplished.  The outcome of the conversation was that they agreed
that this could be done, and that it was a natural extension of some of
Stefan's published ideas.  (He also assured me that the concept was
unencumbered - to his knowledge - by an IP concerns.)

Perhaps we can tap Stefan and ian to help finish the proof and I can finally
finish my paper! ;-)

> Also in protocol part 2:
>         "eXchange -> Advogato: [As(Na), Ss(Ns, 13)]"
> 
> Looks like the exchange party has access to one site's 
> secret key ('Ss')?

My bad - that's simply a confusing description.  Since Slashdot has earlier
passwd 'Ss(Ns, 13)' to eXchange, eXchange now has that opaque token and can
pass it along to Advogato.

=Fen

> Thanks,
> Hans
> 
>> -----Original Message-----
>> From: yadis-bounces at lists.danga.com 
>> [mailto:yadis-bounces at lists.danga.com] On Behalf Of Fen Laballme
>> Sent: Monday, February 13, 2006 12:54 AM
>> To: Drummond Reed
>> Cc: Graves, Michael; yadis at lists.danga.com
>> Subject: Re: OpenID, YADIS and Directed Identity
>>
>> There are some interesting cryptographic properties that you 
>> can attach to a set of nyms that can help to minimize data 
>> correlation (real person triangulation).  I describe a few of 
>> these in an unpublished (and never really completed) paper 
>> that may offer some useful insights at 
>> <http://www.openprivacy.org/papers/200104-repcap.html>.  I 
>> reproduce the most relevant section here:
>>
>> Nym Properties
>>
>> Privacy is ensured through the use of Nyms that have some 
>> very special properties. Given
>>
>>     * T = (Trusted) Parent Nym that can create Child Nyms
>>     * Ci, Cj and Ck are a set of child Nyms created by the 
>> same parent T
>>     * Ei is a child Nym from another parent
>>
>> We can show:
>>
>>    1. Ci, Cj, and Ck cannot prove that T is their Parent
>>    2. Ci, Cj, and Ck cannot prove they are siblings
>>    3. T can separately prove parenthood of Ci and/or Cj
>>          1. without also leaking information about any other siblings,
>>             e.g. Ck
>>    4. T can anonymously prove Ci and Cj are siblings
>>          1. without also leaking information about any other siblings,
>>             e.g. Ck
>>          2. and without leaking information that points to T 
>> as C's parent
>>    5. T cannot prove anything about E
>>
>> =Fen
>>
>>
>> Drummond Reed wrote:
>>> Michael,
>>>
>>> We in XRI-land got the same feedback about the need for 
>> unidirectional 
>>> identifiers for single sign-on last fall. And we came up 
>> with the same 
>>> solution -- see my blog post at:
>>>
>>> http://www.equalsdrummond.name/index.php?p=56
>>>
>>> I think it applies to XRIs, URLs, or any other identifier 
>> technology. 
>>> One caveat I'll point out, though: this technique only 
>> works if there 
>>> are a sufficiently large enough set of identifiers issued by the 
>>> identity service provider (in your example, idsrus.com). 
>> Otherwise you 
>>> can be correlated at that level.
>>>
>>> =Drummond (http://xri.net/=drummond.reed)
>>>
>>> -----Original Message-----
>>> From: yadis-bounces at lists.danga.com 
>>> [mailto:yadis-bounces at lists.danga.com]
>>> On Behalf Of Michael Graves
>>> Sent: Sunday, February 12, 2006 12:40 PM
>>> To: yadis at lists.danga.com
>>> Subject: Re: OpenID, YADIS and Directed Identity
>>>
>>> Johannes Ernst <jernst+lists.danga.com <at> netmesh.us> writes:
>>>
>>>>> ... in my
>>>>> scenario, you wouldn't enter "mart.whatever.com" at the initial 
>>>>> login, screen.
>>>>> Instead you would only enter "whatever.com". At this point, then, 
>>>>> the replying part only knows you are somehow attached to 
>>>>> "whatever.com". You are then redirected (302) to whatever.com's 
>>>>> login page. Unlike the current scenario, the identity server 
>>>>> (whatever.com) has at this point no idea who you are, so 
>> instead of 
>>>>> asking just for your password and presenting the "user"
>>>>> field
>>>>> already filled out, you would need to specify your user name at 
>>>>> whatever.com's login screen as well.
>>>> Not necessarily. The identity server can have a cookie, 
>> shared only 
>>>> with itself, that identifies who you are. So the sequence would be
>>>>
>>>> GET relying-party -> HTML form
>>>> POST relying party identity=whatever.com -> Redirect to 
>> whatever.com 
>>>> GET whatever.com cookie=myid -> Redirect to whatever.com/myid GET 
>>>> whatever.com/myid -> Redirect to relying party with signed URL (if 
>>>> active session, otherwise ask for password first)
>>>>
>>>> P.S. No hunting party as long as everybody understands 
>> that this is 
>>>> about something other than YADIS 1.0.
>>>>
>>>> Johannes Ernst
>>>> NetMesh Inc.
>>>>
>>>>
>>>>
>>>>
>>>> http://netmesh.info/jernst
>>>>
>>>>
>>> Hi Johannes!
>>>
>>> You're right, of course. My point was to emphasize the fact 
>> that the 
>>> identity server has no idea who you are *from* the relying party, 
>>> which means that subsequent provisioning of a generated ID won't 
>>> provide a basis for correlation.
>>>
>>> If you are currently logged in to your identity server, 
>> your cookies 
>>> can trigger "auto-fill" for your user name, when you are 
>> redirected to 
>>> "whatever.com". That's a good point! So, ergonomically, you haven't 
>>> given up anything important to the relying party yet, but when you 
>>> arrive at whatever.com's site, it may know who you are 
>> through its own 
>>> devices and thus you haven't really lost any momentum in 
>> the process.
>>> That's cool. I don't know what the real need/demand is for this 
>>> functionality, but I do know that I've had to defend/address 
>>> YADIS/OpenID not having it several times in the past few 
>> weeks. Again 
>>> this is really an OpenID issue, not a YADIS one, and one we 
>> can take 
>>> up later. This is an interesting "upgrade"
>>> to
>>> consider, though.
>>>
>>> -Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>
> 

-- 
http://public.xdi.org/=Fen.Labalme