OpenID, YADIS and Directed Identity

Fen Labalme fen at
Mon Feb 13 22:12:30 UTC 2006

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:

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.


> Thanks,
> Hans
>> -----Original Message-----
>> From: yadis-bounces at 
>> [mailto:yadis-bounces at] On Behalf Of Fen Laballme
>> Sent: Monday, February 13, 2006 12:54 AM
>> To: Drummond Reed
>> Cc: Graves, Michael; yadis at
>> 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 
>> <>.  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:
>>> 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, 
>> Otherwise you 
>>> can be correlated at that level.
>>> =Drummond (
>>> -----Original Message-----
>>> From: yadis-bounces at 
>>> [mailto:yadis-bounces at]
>>> On Behalf Of Michael Graves
>>> Sent: Sunday, February 12, 2006 12:40 PM
>>> To: yadis at
>>> Subject: Re: OpenID, YADIS and Directed Identity
>>> Johannes Ernst < <at>> writes:
>>>>> ... in my
>>>>> scenario, you wouldn't enter "" at the initial 
>>>>> login, screen.
>>>>> Instead you would only enter "". At this point, then, 
>>>>> the replying part only knows you are somehow attached to 
>>>>> "". You are then redirected (302) to's 
>>>>> login page. Unlike the current scenario, the identity server 
>>>>> ( 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 
>>>>>'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 -> Redirect to 
>>>> GET cookie=myid -> Redirect to GET 
>>>> -> 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.
>>> 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 
>>> "". That's a good point! So, ergonomically, you haven't 
>>> given up anything important to the relying party yet, but when you 
>>> arrive at'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


More information about the yadis mailing list