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

> On 25 Sep 2015, at 11:36, Dave Raggett <dsr@w3.org> 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.

Intriguing but still very cryptic. Here are some questions:

1) An account on a web site is easy to translate to a long lasting identifier. Just assume that each
account has a number, then the site  ( Consumer, a.k.a Relying Party ) can create a URL from 
that account such as  https://example.com/account/23
If take a FIDO account, the identifier is a public key, which is a pretty long lasting identifier

2) Your definition of a lasting identity is a set of attributes associated with the account. Perhaps
such as this?

@prefix foaf: <http://xmlns.com/foaf/0.1/>

<https://example.com/account/23> a foaf:OnlineAccount .
<https://example.com/account/23#> foaf:account <https://example.com/account/23>;
             foaf:openid <https://joe.blogs/> ;
             foaf:mbox <mailto:joe@company.com> .

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

So I suppose you are imagining a session now with another origin ( not example.com ), perhaps this session information is passed via the browser?

So say three people in organisation A, B, and C want to communicate regularly over a few years, but they don't want to be using the same origin for their identity. How do they communicate? How do they express a social network that spans those?

> This is analogous to the design criteria for W3C web platform APIs where we aim to minimise privacy related information leakage through that API.
> 
> There will be a case for credentials for long lived identifiers, e.g. electronic passports, but this doesn’t mean that we should encourage them for every day needs.

Passports are state certified identities, and I agree one should not need to use those for every day needs.

But there is a huge space of possibilities for global identifiers that are pseydonymous, self certified, or even don't enable location of the server using even onion URLs [1] on which one can build decentralised networks with no center of control.  

[1] https://www.ietf.org/blog/2015/09/onion/ <https://www.ietf.org/blog/2015/09/onion/>
> 
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
> 
> 
>