<div> </div>
<div>The signed certificate is a SAML document that needs to be stored at the OP. As of now it is static with the AP generating the certificates off line which are later retrieved by the RP by doing a fetch request (AX) from the OP. The OP stores it in its database as an attribute value pair with the openid. We are using xmlsec to sign the SAML assertions which follow the format in this draft:</div>
<p>draft: <a href="http://www.mail-archive.com/specs@openid.net/msg00907.html">http://www.mail-archive.com/specs@openid.net/msg00907.html</a></p>
<p><br>We could extend the implementation to support references to external signatures, i.e. we could basically stick a URL in the signature attribute and force the RP to fetch the URL.</p>
<div>Neither dynamic nor static certificates are all-purpose solutions, so it's reasonable to support both. For example, a certificate that a user is over 18 could be static with a relatively long validity lifetime, but a certificate that a user has a non-zero bank-account balance should be dynamic.<br>
-</div>
<div><br>Santosh Subramanian.</div>
<div>Shishir Randive</div>
<div>Rob Johnson</div>
<div> </div>
<div class="gmail_quote">On Wed, Oct 29, 2008 at 11:32 PM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div lang="EN-US" vlink="purple" link="blue">
<div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Does the signed "certificate" (attesting to the fidelity of some attribute value) really need to be "stored" –or can it be signed dynamically, before or during release to the RP?</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">The model of dynamic signing "attributes" is of course what happens in OpenID's XRI resolution (trusted variety). The format of the "certificate" supporting the attribute happens to be XML (using a funky variant of the SAML tags), and its signed using xmldsig, supported by CA certs.</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">If the attribute being queried is one managed by an XRI repository, the AX/OP agent could be</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p style="TEXT-INDENT: -0.25in"><span style="FONT-SIZE: 11pt; COLOR: #1f497d"><span>(a)<span> </span></span></span><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Proxying an attribute request in the form of an encoded XRI request, and chaining that request and the response between the XRI agent and the consumer/RP</span></p>
<p style="TEXT-INDENT: -0.25in"><span style="FONT-SIZE: 11pt; COLOR: #1f497d"><span>(b)<span> </span></span></span><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Obtaining the attribute value (via XRI or other resolvers),and packaging it as the XML response (an XRDS with embedded "SAML-certificate-signatures").</span></p>
<p style="TEXT-INDENT: -0.25in"><span style="FONT-SIZE: 11pt; COLOR: #1f497d"><span>(c)<span> </span></span></span><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Lookup the attribute value from a simple db, and return the certified form…or certify it on the fly – using XRI's SAML-certificates or X.509 PACs, …or **any other** form of signed certificate</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<div style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<p><b><span style="FONT-SIZE: 10pt">From:</span></b><span style="FONT-SIZE: 10pt"> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>] <b>On Behalf Of </b>santosh subramanian<br>
<b>Sent:</b> Wednesday, October 29, 2008 5:57 PM<br><b>To:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br><b>Cc:</b> Michael Hart; Rob Johnson; Shishir<br><b>Subject:</b> [LIKELY_SPAM]Re: [OpenID] Too many providers and here's one reason</span></p>
</div>
<div class="Ih2E3d">
<p> </p>
<div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p>For example, a dating site might need to verify a user's age before letting them log in. In our solution, one party, which we call the Attribute Provider (AP), provides<br>a signed certificate that the the user possesses some attribute (e.g. is over 18). This certificate is stored as an attribute at the user's OP, and other RPs can request this certificate when they want to verify attributes of the user.</p>
</div>
<div>
<p><span style="COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p>For the implementation, we have followed the OpenID Signed Assertions</p></div>
<div>
<p>draft: <a href="http://www.mail-archive.com/specs@openid.net/msg00907.html" target="_blank">http://www.mail-archive.com/specs@openid.net/msg00907.html</a></p></div>
<div>
<p><br><br></p></div>
<p> </p></div></div></div></blockquote></div><br>