[Openid-specs-ab] Distributed Data Model

John Bradley ve7jtb at ve7jtb.com
Wed Nov 17 18:16:32 UTC 2010


I think there are cases where non link-ability by the claim issuer is important, and in those cases having a cloud selector or smart client that passes the blinded assertion makes sense.    Though the cloud selector service itself becomes a point of link ability.

In a lot of cases the claims may be to simple claims providers returning assertions or more complicated API type services (Facebook Graph API) etc.

In a lot of cases Equifax as an example the billing relationship, revocation requirements and desire to know the Privacy policy of the RP makes unlink-ability not work well for some use cases.

There may also be different liability issues for the IdP depending upon if the IdP is returning a value or a token for the RP to retrieve the value directly.

I think we need to support both models over time.

We need a way to do U-Prove with JSON tokens and process that on the client in PHP before we can make everyone by into the u-prove token.

I have always been a supporter of Stefan and IBM's work on that over the years.

I don't think openID AB itself should have a direct dependancy on u-Prove, it should however be extensible to support it.

John B.


On 2010-11-17, at 2:26 PM, Anthony Nadalin wrote:

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101117/b733dd65/attachment.bin>


More information about the Openid-specs-ab mailing list