[Openid-specs-ab] Distributed Data Model

Nat Sakimura sakimura at gmail.com
Mon Nov 15 22:12:56 UTC 2010


Hi.

AB had some incomplete distributed data model.
For the complete one, we were differing it to CX because it requires
some kind of "token resolution service", which is an extra round-trip.

Now that we are harmonizing with Connect which requires the UserInfo
endpoint, which is effectively such an endpoint, I feel that there is
no reason why we cannot do this in AB. (That means CX is getting
thinner and thinner...)

The model is like this:

1. RP sends the list of all the attributes it wants.
2. User gets authenticated at the OP and authorizes the attribute request.
3. RP gets the assertion like:

{
    "openid": {
        "type": "http://openid.net/specs/ab/1.0#id_res",
        "server_id": "https://op.example.com/",
        "pubkey": "CSqGSIb3DQEBBQ...22WLTnPvcztaqovGW2gaidAyq6",
        "request_uri": "https://rp.example.com/rf.js%23Qfsoe2F",
        "op_endpoint": "https://op.example.com/op_endpoint",
        "claimed_id": "https://example.com/alice#1234",
        "identity": "alice",
        "user_id": "https://op.example.com/a3flsjeow1234",
        "issued_at": 1280217103,
        "client_id": "https://rp.example.com/",
        "acccess_tokens": [
          {
            "endpoint":"https://op.example.com/refr",
            "token":"SIAV32hkKG2",
            "expires_in":3600
          },
          {
            "endpoint":"https://data.example.org/data_api",
            "token":"GKkh23VIAs3",
            "expires_in":3600
          }
        ]
    },
    "access_token": "SlAV32hkKG",
    "expires_in": 3600,
    "refresh_token": "8xLOxBtZp8"
}

Top level "access_token" is the usual OAuth access token.
Twist is the "access_tokens". It is an array of JSON objects that
describes the endpoint, token, and its expiry period.

4. The client makes a call to one of the endpoint.
5. The endpoint server makes a call to the UserInfo endpoint to obtain
  (a) Validity of the token
  (b) List of authorized variables for release
  (c) User's PPID/the endpoint specific Local Identifier.
6. The endpoint server returns what was sought, optionally signed and
encrypted.

Asymmetric encryption is handy replacement to the client authentication.
It also protects the confidentiality.
If it is signed, the returned result itself can be used as a kind of "token".
For example, if it contained a claim that the user is "over 18",
it can be presented to other servers to prove the claim, this time
without any knowledge of the OP or the endpoint server.



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en


More information about the Openid-specs-ab mailing list