[OpenID] Laws of id, openid with ssl

[Drummond Reed]

George, I was only pointing out that only three parties need to know about a
directed identifier -- the RP, the OP, and the user -- and of these, only
the OP and the user know it is associated with the user. In practice, it's
actually just the OP who knows this - it will store the directed identifier
for the user, so all the user has to remember is their own OpenID identifier
(or let a cookie do that for them) and their password.

So even though the RP resolves the directed identifier on the public
Internet, all it reveals is that it points to the OP. Only the OP and the
user knows who it points too inside the OP -- unlike an omnidirectional
OpenID identifier (like a blog URL), where anyone can discovery who it
points to.

That's why it very much is private -- were either the OP or the user to
publish it in a way that associated it with the user, the RP would be able
to discover the public identity of the user.

=Drummond 

> -----Original Message-----
> From: George Fletcher [mailto:gffletch at aol.com]
> Sent: Friday, January 25, 2008 8:37 AM
> To: 'OpenID List'
> Cc: Drummond Reed; 'Martin Atkins'
> Subject: Re: [OpenID] Laws of id, openid with ssl
> 
> Hmm... I agree that the OpenID is "not intended to be public" but the
> fact of the matter is that the RP has to resolve the "directed identity"
> OpenID to verify that the OP is authoritative for that OpenID. In that
> sense (unless all this is behind some firewall) the OpenID is "public".
> 
> Initially I was thinking that the "pseudonymous" term from SAML would be
> applicable but maybe Martin's "obfuscated" term is more applicable? (I
> think I could go with either).
> 
> However, should "directed identity" OpenIDs NOT be "browser" resolvable?
> Any best practices on what the OP should do in this case? Is there data
> exposure if the OP says that it's not authoritative for
> https://op.example.com/abcde but is authoritative for
> https:/op.example.com/bcdef?
> 
> Given that hopefully all this traffic is over SSL, the ability to find
> these identifiers and correlate them to some public usage should be
> difficult.
> 
> Thanks,
> George
> 
> Drummond Reed wrote:
> >> -----Original Message-----
> >> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> >> Behalf Of Martin Atkins
> >> Sent: Thursday, January 24, 2008 4:27 PM
> >> Cc: 'OpenID List'
> >> Subject: Re: [OpenID] Laws of id, openid with ssl
> >>
> >> Drummond Reed wrote:
> >>
> >>> Peter, just to reinforce Dick's first step below -- in directed
> >>>
> >> identity,
> >>
> >>> the user does not give their own public identifier to the RP, only the
> >>> identifier of their OP. That way the RP knows how to discover the OP's
> >>>
> >> XRDS
> >>
> >>> and connect to the service endpoint for the OP's directed identity
> >>>
> >> service
> >>
> >>> (<Type>http://specs.openid.net/auth/2.0/identifier_select</Type>).
> >>>
> >>> The OP then returns the user's selected identifier (either public or
> >>>
> >> private
> >>
> >>> -- user's choice).
> >>>
> >>>
> >> I think calling it a "private" identifier is a bit misleading. All
> >> OpenID identifiers are public.
> >>
> >> Perhaps a terms to use would be "obfuscated", "single-use" or
> "throwaway".
> >>
> >
> > Disagree. A pairwise-unique identifier generated by an OP is not
> intended to
> > be public. If it was shared publicly, i.e., could be associated with the
> > public identifier of the user, it would lose its capability to privately
> > identify the user's relationship with the RP.
> >
> > An OP-generated pairwise-unique identifier is the OpenID equivalent of
> the
> > PPID ("Private Personal Identifier") in Cardspace.
> >
> > =Drummond
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >