[project @ OpenID Signed Assertions(Implementation of old sxip draft)]

  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

The Signed Assertions Draft did not specify how signed assertions are
stored at the OP, so we adopted the following scheme:
 Attribute:    http://X
 Certificate:  http://X/signature
This enables RPs that don't care about certificates to completely ignore them.  Assertions are SAML documents as specified in the OpenID Signed
Assertions old draft.
We are developing a demo application in which a university issues certificates verifying students' age, student-hood, and even their photo (also potentially useful to dating sites).  So basically the university acts as an attribute provider, signing assertions about user claims. These claims are stored as an attribute in the OpenId provider and we can use the OpenID AX protocol to pass assertions as attributes.  The data flow is:
   User requests assertion --- University(Attribute provider)
                           --- (store request)
                           --- Openid provider
   Relying Party(Dating site) --- (fetch request) --- OpenID Provider
The RP gets the assertion, verifies the signature, and takes actions depending on the result.  In some scenarios, the RP may deny the user request if the attribute verification fails (e.g. the dating site may forbid users under 18).  In other scenarios the RP may treat them differently (e.g. the dating site could tag certified photos as "Verified Photo").
Note that the RP must have some sort of trust relationship with the AP.  We've tried to keep the system as open as possible.  Our protocol and implementation do not specify how this trust relationship is created or managed.  For example, there could be a PKI specifically set up for verifying claims about student-hood, another trust system set up for verifying claims about age, etc.
 
Santosh Subramanian
Shishir Randive
Michael Hart
Rob Johnson

0 files changed, 0 insertions, 0 deletions