[OpenID] [LIKELY_SPAM]Re: Too many providers and here's one reason

[santosh subramanian]

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:

draft: http://www.mail-archive.com/specs@openid.net/msg00907.html


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.
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.
-

Santosh Subramanian.
Shishir Randive
Rob Johnson

On Wed, Oct 29, 2008 at 11:32 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  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?
>
>
>
> 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.
>
>
>
> If the attribute being queried is one managed by an XRI repository, the
> AX/OP agent could be
>
>
>
> (a)    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
>
> (b)   Obtaining the attribute value (via XRI or other resolvers),and
> packaging it as the XML response (an XRDS with embedded
> "SAML-certificate-signatures").
>
> (c)    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
>
>
>
>
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *santosh subramanian
> *Sent:* Wednesday, October 29, 2008 5:57 PM
> *To:* general at openid.net
> *Cc:* Michael Hart; Rob Johnson; Shishir
> *Subject:* [LIKELY_SPAM]Re: [OpenID] Too many providers and here's one
> reason
>
>
>
>
>
> 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
> 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.
>
>
>
>
>
> For the implementation, we have followed the OpenID Signed Assertions
>
> draft: http://www.mail-archive.com/specs@openid.net/msg00907.html
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081030/9e48742c/attachment-0002.htm>