This repository has been archived by the owner on Feb 24, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CHANGELOG
60 lines (47 loc) · 3.68 KB
/
CHANGELOG
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Tue Apr 21 10:54:38 PDT 2009 [email protected]
tagged 2.1.3
Ignore-this: c326c9655a045adeb45a9b153bd2a357
Mon Apr 20 12:44:23 PDT 2009 [email protected]
* Consumer: require that op_endpoint be signed in id_res responses
Ignore-this: 6598d5e0768bf410105eef7ac24da698
Fri Dec 12 12:13:44 PST 2008 [email protected]
* Unify method signatures to reduce E_STRICT warnings
Mon Dec 8 15:39:36 PST 2008 [email protected]
* Move signed assertions code into contrib/
Fri Nov 14 14:07:59 PST 2008 [email protected]
* 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/[email protected]/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 [email protected]
* Message: indentation
Fri Nov 7 12:24:12 PST 2008 [email protected]
* 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 [email protected]
* Don't use Range header for ID page requests
Tue Sep 9 12:10:58 PDT 2008 Kevin Turner <[email protected]>
tagged 2.1.2