OpenID, YADIS and Directed Identity

[Granqvist, Hans]

Hi Fen, 

Do you have the cryptographic proof (it's missing 
from the 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')?

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