More use cases

[Dick Hardt]

On 10-Oct-06, at 5:14 PM, Johannes Ernst 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.
>
> This does appear to address the "no modification in transit" part  
> of the requirement, but it does not appear to address the "leak  
> information in transit". Right?

leaking information between AP and user and user and AR is easily  
accomplished with SSL

If the user wants to leak their data, then there is not much to stop  
them.

If you really were concerned though, the AP could encrypt the data  
with the AR's public key as well.

>
>> I have drawn pictures of this on white boards a number of times  
>> for you. :-)
>
> You must mistake me for somebody else :-)

that would be impossible to do

>
>>>>> 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?
>
> Use case pasted in from previous message:

I deleted for a reason. It is not all the illuminating. How about a  
relevant one?

>
>> Customer: "where is the engagement ring I ordered?"
>> Company: "it shows here that it was delivered a week ago".
>> Customer: "was not."
>> Company: "was, too."
>> Customer: "did you give it to my neighbors?"
>> Company: "no, it was delivered on the door step of 123 Main street  
>> at 11:23am."
>> Customer: "what do you mean 123 Main Street, that's the appartment  
>> of my ex!!"
>> Company: "well, we executed this OpenID query and, yep, if I drill  
>> down into the protocol log, it does say that two IdPs provided  
>> conflicting statements, but we trusted A Corp. more than B Corp.  
>> and that's where we sent it"
>> Customer: "darn, I must have forgotten to update B Corp's. IdP on  
>> this attribute". ("and simply clicked through when it asked me  
>> whether I wanted to release this claim" -- assuming a DIX-style  
>> browser interaction -- but it's really independent of the  
>> mechanism of data exchange)
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
> <lid.gif>
>  http://netmesh.info/jernst
>
>
>
>