More use cases

[Johannes Ernst]

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

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

You must mistake me for somebody else :-)

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20061010/6a306eb7/attachment-0002.gif>
-------------- next part --------------
  http://netmesh.info/jernst