- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 25 Sep 2015 09:48:54 -0400
- 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