[Openid-specs-ab] Distributed Data Model

Anthony Nadalin tonynad at microsoft.com
Wed Nov 17 17:26:02 UTC 2010

> There are models where the IdP fetches tokens from the attribute providers directly (RSA/Identity Mixer etc) and then forwards those to the relying party.

This could be problematic in cases where minimum disclosure is required or non linkability  may be required 

-----Original Message-----
From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
Sent: Tuesday, November 16, 2010 3:49 PM
To: Anthony Nadalin
Cc: Nat Sakimura; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Distributed Data Model

We haven't looked at bidirectional attribute negotiation yet.

We were describing the simple IMI/AX like claims model of the RP requesting a set of claims.  

It would be up to the IdP to provide a UI giving the user the choice of particular attribute providers to satisfy the requested set.

I see attribute providers being part of a trust framework infrastructure along with IdP/smart client.

Ideally if a user has a smart client they could manage there claims directly.   Without that they need an identity provider that can provide basic LoA guarantees around their account and provide the binding for 3rd parties to provide claims relative to the account.

There are models where the IdP fetches tokens from the attribute providers directly (RSA/Identity Mixer etc) and then forwards those to the relying party.

The model we are exploring is one where the attribute providers are RestSTS like and the RP directly trades an oAuth access token for a signed and encrypted claims token.

Nat and I discussed it a bit more last night.  My preference is to include all of the information/claims the RestSTS needs in the encrypted oAuth access token.

That way the RestSTS won't need to make a separate round trip to the IdP.   I think that will work better with smart clients.

I talked to your IBM Zurich friends about extending the claims architecture to allow attribute predicates in requests and assertions.

eg  age > 18  

This may be something useful for U-Prove as well.

At the moment we are using AX type claims,  adding a extension for a more sophisticated model would be a great thing.

The first step is exploring the RestSTS and how to exchange provisioning meta-data with the IdP.   (like installing a infocard but not)  Perhaps using oAuth to connect the Attribute provider with the IdP.

Lots of work to be done.  Happy to have you help.  

John B.

On 2010-11-16, at 3:58 PM, Anthony Nadalin wrote:

> 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
> _______________________________________________
> 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