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

On 09/24/2015 04:41 PM, Martin Paljak wrote:
> On 24/09/15 21:50, Harry Halpin wrote:
>> Note that use of OAuth does *not* violate SOP because it asks for
>> and gets permissions, and the data transfer is done
>> server-to-server. Client-based sending of personal data has real
>> difficulty in a multi-device world due to issues of syncing and
>> devices being offline. However, you can *do* data transfer
>> server-to-server with digital signatures and anonymizing property.
>> But building from these kind of OAuth data-flows is probably the
>> way to go, where key material can be dynamically bound to the
>> session (ala TLS Token Binding) so avoiding "one key per user"
>> designs. This slide-deck is a good overview [3].
>
>
> Maybe this outlines one the problems I'd like to see avoidable as a
> required piece of the "web identity" puzzle, if possible: dependence
> on central, *on-line* identity providers (what server-to-server
> communication depends on). That's a SPOF that has amplification
> capability which is not desirable.

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.

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

Received on Thursday, 24 September 2015 21:03:13 UTC