[Openid-specs-ab] Distributed Data Model

Anthony Nadalin tonynad at microsoft.com
Tue Nov 16 18:58:22 UTC 2010


Do you see #1 and #2 as negotiations ? That is you want x and y and I only want you to have y. Also how do you see the assertion being validated as something that the RP can trust?

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, November 15, 2010 2:13 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Distributed Data Model

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
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list