[OpenID] ANN: OpenID Information Cards spec andworkingimplementation

Sun Aug 26 18:38:11 UTC 2007

I think I'm ready to comprehend your document's meaning, next week.

"From a very high level, the TokenProcessor works as follows. The token
is encrypted using the Web site SSL certificate. The TokenProcessor uses
the thumbprint of this certificate to find the associated private key,
defaulting to the My/LocalMachine store. [..] The decrypted result is
then converted into a SamlToken and validated [...]. Once validated, a
reference to the token and its claims are available to your code as
shown earlier.

http://msdn.microsoft.com/msdnmag/issues/07/04/Identity/default.aspx

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.

It makes sense in TPEP doctrine that the NT (or Trusted Solaris) Trusted
Path SEFs on the cardspace-enabled host might leverage SSL to enforce
those intendedRecipient security controls. This is entirely consistent
with the Network model of the TCSEC, often repurposed by the likes of
Sony in the DRM world. Adding TPM strength  and assurance to SSL's key
distribution/management (and therefore Cardspace) is optional, of
course.

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

------------

Ok. We can outline what the Microsoft OpenID implementation MIGHT look
like (and, NB, I don't actually know!). Surely, they have to be doing
something better than merely trusted layed7 gatewaying between two
protocol suites!

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.

The Cardspace Trusted Path feature could still supporting the trusted
HTTP browser's usermode process, when handling the direct-channel
communications between the RP website and the Cardspace-IP/OP-Server. It
can still enforce the constraints of the N-TCB concerning how the
intendedRecipieing SHALL behave (when cooperating with
anti-phishing/identity-theft countermeasures derived from the N-TCB
properties)

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.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Johnny Bufu
Sent: Wednesday, August 22, 2007 11:20 AM
To: Broberg, Jeffrey C
Cc: OpenID List
Subject: Re: [OpenID] ANN: OpenID Information Cards spec
andworkingimplementation

Hi Jeff,

On 22-Aug-07, at 9:25 AM, Broberg, Jeffrey C wrote:

> Does this mean that the RP will have to use SSL and provide a cert ?

The current version of Cardspace requires RPs to use HTTPS / SSL,  

however this will not be the case in the next version. So HTTP RPs  

will be able to talk to Cardspace (and presumably the other selectors  

available).

Johnny

_______________________________________________

general mailing list

general at openid.net

http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070826/0337bf1c/attachment-0002.htm>