[OpenID] ANN: OpenID Information Cards spec andworkingimplementation

Johnny Bufu johnny at sxip.com
Mon Aug 27 03:52:48 UTC 2007


Hi Peter,

First just want to mention that the official terms are "Information  
Cards" for the protocols (or informal "infocards"), while "Cardspace"  
is Microsoft's implementation.

On 26-Aug-07, at 11:38 AM, Peter Williams wrote:
> It makes sense that a Cardspace IP issues a token to an  
> intendedRecipient, expecting that recipient to enforce ORCON  
> (originator control) policies. If IP and RPs access to SSL is  
> delegated to the TPM’s key management control system, the ORCON  
> policy can even be assured
> I can now see how in OpenIDland we might attempt to rely on OpenID  
> Associations, rather than SSL sessions, with or without TPM acting  
> as the gatekeeper to an association store. Similarly, I can see how  
> might leverage the WS* controls in a SAML artifact resolution SOAP- 
> exchange, using means discussed in http://www.oasis-open.org/ 
> archives/ws-rx/200605/msg00160.html
Yes, the intended recipient is ensured by employing the OpenID  
signatures (based on private associations), which live inside the  
OpenID authentication responses that are in turn encapsulated in  
infocard tokens.

> So. Cardspace IPs are not required to issue signed SAML tokens,  
> being token-blob independent. They are not actually REQUIRED to  
> issue tokens via ws-federation, either. They might simply issue  
> OpenID Auth CheckID responses, given OpenID Auth flows between  
> browser/TrustedProcess and OpenID-server. This WOULD dispose of the  
> burden on the RP of decoding SAML blobs, handling xmldsig, and  
> needing to leverage ws-fed to talk to STSs.
Not sure about the second part (about identity providers not using  
the WS-* protocols when sending infocard messages), but our proposed  
flow definitely doesn't use SAML tokens. What's more, the data posted  
by the selector to the RP is not necessarily always encrypted: for a  
auditing-enabled managed card the it is whatever the identity  
provider put in the selector-opaque token blob (in our case the  
<openid:OpenIDToken> element).

> OK. I see how one can argue that OpenID replaces ws-fed/SAMLTokens,  
> and it can still be called Cardspace. Cardspace is after all mostly  
> the discovery protocol and the NT Trusted Process hooks … not ws- 
> fed, token formats or the claimset definitions.
I wouldn't go as far as saying that it replaces the SAML in infocard  
interactions, but it's an alternative.


Johnny





More information about the general mailing list