W3C home > Mailing lists > Public > public-web-security@w3.org > September 2015

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

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Fri, 25 Sep 2015 09:48:54 -0400
Message-ID: <560550C6.3030809@digitalbazaar.com>
To: Dave Raggett <dsr@w3.org>, Melvin Carvalho <melvincarvalho@gmail.com>
CC: Martin Paljak <martin.paljak@ria.ee>, public-web-security@w3.org
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
Received on Friday, 25 September 2015 13:49:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:38 UTC