[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