More use cases

[Johannes Ernst]

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?

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

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)

We could simply say that as phrased, it's not allowed. The user --  
well, really their IdP -- can always offer "data reconciliation  
services" through a level of indirection ...


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/20061009/7edf21af/attachment-0002.gif>
-------------- next part --------------
  http://netmesh.info/jernst