<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText>I think I’m ready to comprehend your document’s
meaning, next week.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>"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.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><a
href="http://msdn.microsoft.com/msdnmag/issues/07/04/Identity/default.aspx">http://msdn.microsoft.com/msdnmag/issues/07/04/Identity/default.aspx</a><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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 <a href="http://www.oasis-open.org/archives/ws-rx/200605/msg00160.html">http://www.oasis-open.org/archives/ws-rx/200605/msg00160.html</a><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>------------<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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!<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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)<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>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.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>-----Original Message-----<br>
From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf
Of Johnny Bufu<br>
Sent: Wednesday, August 22, 2007 11:20 AM<br>
To: Broberg, Jeffrey C<br>
Cc: OpenID List<br>
Subject: Re: [OpenID] ANN: OpenID Information Cards spec
andworkingimplementation<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Hi Jeff,<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>On 22-Aug-07, at 9:25 AM, Broberg, Jeffrey C wrote:<o:p></o:p></p>
<p class=MsoPlainText>> Does this mean that the RP will have to use SSL and
provide a cert ?<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>The current version of Cardspace requires RPs to use
HTTPS / SSL, <o:p></o:p></p>
<p class=MsoPlainText>however this will not be the case in the next version. So
HTTP RPs <o:p></o:p></p>
<p class=MsoPlainText>will be able to talk to Cardspace (and presumably the
other selectors <o:p></o:p></p>
<p class=MsoPlainText>available).<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Johnny<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>general mailing list<o:p></o:p></p>
<p class=MsoPlainText>general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>http://openid.net/mailman/listinfo/general<o:p></o:p></p>
</div>
</body>
</html>