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
