[OpenID] Laws of id, openid with ssl

Peter Williams pwilliams at rapattoni.com
Thu Jan 24 21:15:10 UTC 2008


I'm missing something. This is not surprising, since all I really have is the protocol spec from which I attempt to infer the design/security model. To be wholly truthful, I'm also relying on page 50 of http://www.openidbook.com/chapters/OpenIDBook-Draft-13.pdf to paint the big picture I'm after. lets write-up out the protocol flow I think is at the heart of the enforcement claim:
 
1 User (in control) introduces him/herself to RP site, with a public openid. That is: "please complete public discovery". I support the UCI doctrine, so I the user always use a public openid for this.
 
2 RP Site applies YADIS, to retrieve a public XRD. Per UCI thesis, this **user**-controlled stream identifies many OPs and their various component services. Lets say that each one uniquely bind to (one of ) the user's private identifier, one per RP in the worst case.
 
3 OpenID2 Auth now continues with an OP, post discovery, initiated by RP1. The OP (known as OP1, now) is selected by matching RP1 requirements to the delegated openid in one of the public XRD entities.
 
4 OpenID delegation procedures occur during RP1's handling of OpenID auth messages sent by OP1, based on the notion of trusted "realms". Those procedures allow not only the presentation of the appropriate private ID to RP1 but also obtain the assertion of the id and any associated attributes by the particular OP managing that private identifier.
 
5 Unlike SAML2, there are no controls in openid2 preventing the OP from provisioning the XRD-nominated (but perhaps not yet provisioned)  private ID on the fly.
 
---------
 
Now, when we say that OpenId2 supports directed identity (complying with Law 4), is the above flow pattern what we mean?
 
 
Are there other openid flow patterns that are INTENDED to satisfy the control objective of "directed identity"? For example, the XRD is private, not public. For example, the openid used during discovery a given RP is a private (unidirectional) id, not an omnidirectional id?
 
----------
 
PS The flow I outlined seems very little different to how Visa/Mastercard's financial webSSO works (in the 1997-era 3dsecure standards), where virtual and/or use-once PANs (visa card numbers) could be manufactured by the various merchant/acquirer gateways (acting as asserting parties), for consumption by particular communities of merchants subscribing to particular "managed risk models" - ultimately serviced by VISANet.
 
 

________________________________

From: Drummond Reed [mailto:drummond.reed at cordance.net]
Sent: Thu 1/24/2008 12:19 PM
To: Peter Williams; 'OpenID List'
Subject: RE: [OpenID] Laws of id, openid with ssl



> Peter Williams wrote:
> Law 4:directed identity. Enough said. The mission of uci is contrary to
> this law? Surely? Uci thesis essentially denies the legitinmacy of the
> notion of private identities.

Peter, the directed identity feature in OpenID 2.0 fully supports directed
identity. Thus I would not say the "user-centric identity thesis" denies the
legitimacy of the notion of private identities at all. Rather user-centric
identity means the user is in control of the identifiers. As of OpenID 2.0,
a user can have two types of user-centric identifiers: public identifiers
(what Law 4 calls "omnidirectional identifiers") that can be shared
publicly, and private identifiers (what Law 4 calls "directional
identifiers") which are not intended to be shared publicly.

=Drummond






More information about the general mailing list