RE: A Somewhat Critical View of SOP (Same Origin Policy)

Thanks for completing your use case on the wiki dedicated to that topic, guys !
https://www.w3.org/Security/wiki/IG/a_view_on_SOP


Regards,
Virginie


-----Original Message-----
From: Dave Longley [mailto:dlongley@digitalbazaar.com]
Sent: vendredi 25 septembre 2015 15:49
To: Dave Raggett; Melvin Carvalho
Cc: Martin Paljak; public-web-security@w3.org
Subject: Re: A Somewhat Critical View of SOP (Same Origin Policy)

On 09/25/2015 06:36 AM, Dave Raggett wrote:
>
>> On 25 Sep 2015, at 11:08, Melvin Carvalho <melvincarvalho@gmail.com
>> <mailto:melvincarvalho@gmail.com>> wrote:
>>
>> On 25 September 2015 at 11:38, Dave Raggett<dsr@w3.org
>> <mailto:dsr@w3.org>>wrote:
>>
>>
>>> On 24 Sep 2015, at 22:02, Dave Longley <dlongley@digitalbazaar.com
>>> <mailto:dlongley@digitalbazaar.com>>
>>> wrote:
>>>
>>> We also need to be careful about the privacy implications here.
>>> To explain this I'm going to lay out some quick terminology for a
>>> user-centric system.
>>>
>>> In the Credentials CG work, we have four main parties that are
>>> involved in a "credentials ecosystem". Here's a brief overview:
>>>
>>> 1. Users - entities about which claims are made 2. Issuers -
>>> services that make claims 3. IdPs - services that aggregate claims
>>> on behalf of Users 4. Consumers - services that request and make use
>>> of claims
>>>
>>> Now, regarding privacy, it would be ideal if a User could interact
>>> with Consumers without Issuers or IdPs being made aware of this
>>> fact. If information is going to be transferred "server-to-server",
>>> this property should be preserved.
>>
>> A further desirable property would be that the identifiers used
>> between the User and Consumer are short lived (i.e. session based),
>> to minimise loss of privacy across sessions or across Consumers.
>>
>>
>> There are times when you would certainly wish to use short lived
>> identifiers, for example, when the user does not want to be tracked.
>> But just as in the real world, there are times when the user will
>> have a relationship with the consumer, so that the experience can be
>> personalized to an individual's tastes.  If we consider the real
>> world, both cases are quite common.
>
> Indeed.
>
> However, even where the user and consumer have a long lasting
> relationship, there is no need for credentials to be issued against a
> long lasting identifier.  For instance, the user/device can be
> authenticated in respect to a session id as being the same user/device
> that registered an account. The consumer can bind that account to a
> lasting identity, i.e. a set of attributes associated with the
> account. This account is set up with the consent of the user as part
> of the relationship with the consumer.
>
> By expressing credentials in terms of the session identifier and not
> the account, should the credentials be passed to another party it is
> much harder to tie them to particular users.  This is analogous to the
> design criteria for W3C web platform APIs where we aim to minimise
> privacy related information leakage through that API.

Note that in order to express a credential in terms of the session identifier in this scenario, the Issuer would have to be made aware of it. This may leak the User + Consumer relationship to the Issuer.

I think it would be better to create short-lived bearer credentials in these situations. An Issuer can create one of these or an Issuer or trusted "anonymizer" service could convert a long-lived credential into one of these and then give it to the User. The User can then bind the credential to a particular origin (ie: the Consumer's) by signing it with an anonymous origin-bound key (using, perhaps, FIDO). Then, once the short-lived bearer credential is in the hands of the Consumer, they can map it to whatever internal identifiers they want for the User.


--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com


________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Friday, 25 September 2015 14:38:58 UTC