On 09/25/2015 06:36 AM, Dave Raggett wrote:
On 25 Sep 2015, at 11:08, Melvin Carvalho <melvincarva...@gmail.com
<mailto:melvincarva...@gmail.com>> wrote:
On 25 September 2015 at 11:38, Dave Raggett<d...@w3.org
<mailto:d...@w3.org>>wrote:
On 24 Sep 2015, at 22:02, Dave Longley
<dlong...@digitalbazaar.com <mailto:dlong...@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.
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.
+1, there are use cases for both types of credentials, those that
require long lived identifiers, and those that don't. We want make sure
that we're picking the appropriate type for each use case so we only
have to deal with the disadvantages of each type as needed.
--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com
