ums/lib/php-openid/CHANGELOG

Tue Apr 21 10:54:38 PDT 2009  cygnus@janrain.com
  tagged 2.1.3
  Ignore-this: c326c9655a045adeb45a9b153bd2a357

Mon Apr 20 12:44:23 PDT 2009  cygnus@janrain.com
  * Consumer: require that op_endpoint be signed in id_res responses
  Ignore-this: 6598d5e0768bf410105eef7ac24da698

Fri Dec 12 12:13:44 PST 2008  cygnus@janrain.com
  * Unify method signatures to reduce E_STRICT warnings

Mon Dec  8 15:39:36 PST 2008  cygnus@janrain.com
  * Move signed assertions code into contrib/

Fri Nov 14 14:07:59 PST 2008  subra.santosh@gmail.com
  * 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

Fri Nov  7 12:39:15 PST 2008  cygnus@janrain.com
  * Message: indentation

Fri Nov  7 12:24:12 PST 2008  sam.alexander@vidoop.com
  * getAliasedArg() returns OpenID namespace when $aliased_key is 'ns'
  
  This fixes an rather cryptic error when using stateless mode via the DumbStore.  The 'ns'
  key can not be found in the alias/namespace mapping (its stored as the "Null Namespace"),
  it must be returned explicitly. The inability to find the key in the mapping results in a
  "Server Denied check_authentication" error, but the error is caused before any callback
  to the server is made.
  
  This also brings the PHP lib more in line with the ruby and python libs.
  

Fri Oct 31 16:23:00 PDT 2008  dag@janrain.com
  * Don't use Range header for ID page requests

Tue Sep  9 12:10:58 PDT 2008  Kevin Turner <kevin@janrain.com>
  tagged 2.1.2