More use cases

[Dick Hardt]

On 9-Oct-06, at 10:39 PM, Johannes Ernst wrote:

>
> On Oct 9, 2006, at 14:37, Dick Hardt wrote:
>
>>
>> On 28-Sep-06, at 9:53 AM, Johannes Ernst wrote:
>>
>>> I was asked to forward the following use cases/requirements with  
>>> me playing the anonymizer service, presumably for political  
>>> reasons ;-) These are paraphrased ...
>>>
>>> 1) An Attribute Provider (AP) makes an assertion about some user  
>>> to an Attribute Receiver (AR). (typically an IdP and a RP). The  
>>> assertion is conveyed with the user in the loop. However, the  
>>> device that the user is using to be in the loop is not trusted.  
>>> For example, the device may alter information in transit (add,  
>>> remove, change). Or, it may leak information in transit (e.g.  
>>> post my identity details to Usenet).
>>>
>>> Can OpenID be used to address these requirements? If yes: how? If  
>>> not: could OpenID be modified somehow to address these requirements?
>>>
>>> [Johannes comment: in the age of compromised PCs everywhere, this  
>>> is an interesting question. I'm not sure we can answer it. But it  
>>> sure would be useful if we could say "we can do this".]
>>
>> OpenID will be able to do this with Attribute Exchange.
>
> How?

The AP makes an assertion that an OpenID has an attribute and digital  
signs it.
The user proves to the AR that they are an OpenID using OpenID  
Authentication 2.0, and also provides the assertion from the AP to  
the AR.
The AR verifies the assertion.

I have drawn pictures of this on white boards a number of times for  
you. :-)

>
>>> 2) May a single Persona have multiple attribute exchange  
>>> services? Are there any constraints on those services? For  
>>> example, what happens if there are three, and all three return a  
>>> different date of birth for the same persona? But then, having  
>>> more than one would be very advantageous if their scope was non- 
>>> overlapping: say, one has personal identity data, another work  
>>> identity data etc.
>>>
>>> [Johannes comment: my suggestion would be to build an  
>>> "aggregation" service and declare that one instead, where the  
>>> aggregation service delegates to, and resolves conflicts between  
>>> the underlying data.]
>>
>> If the user can get different claims stating they have different  
>> dates of birth, the "problem" is with the entities making the  
>> claims, not the protocol.
>
> It would be my hope that we're trying to solve a (business,  
> personal, ...) problem, and not simply exclude everything outside  
> of what a protocol can do.

Perhaps you can provide a relevant use case. Is there something  
specific you are thinking of or is this just theory?