W3C home > Mailing lists > Public > public-credentials@w3.org > March 2018

Re: Verifiable Credentials on DID-Auth

From: Carlos Bruguera <cbruguera@gmail.com>
Date: Wed, 28 Mar 2018 10:08:24 +0700
Message-ID: <CAJrRL-GbZS+B4OHuxOuHnHPrFtms9NZLyTphn-ukM=gAB3=Yjg@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: public-credentials@w3.org
Thanks everyone for your responses, it's been quite helpful, and it's
reassuring to know this is an actual case being taken into consideration.

Markus, your write-up is very concise and spot on, thanks a lot for that!

Following that line, I think models #2 and #3 feel like the way to go for
me, since #1 is an unnecessary limitation, while the other approaches still
allow for subsequent credential requests after initial authentication. #2
sounds like the most practical way in terms of implementation, however I
must say #3 looks like a very elegant way to see it (although *perhaps* too
abstract for practical implementation)... I'm still curious about your
personal choice (Markus).

Again, I appreciate all the responses given, and I'm looking forward to see
any related material or discussions on this regard. Thanks.

Best,
Carlos

On Tue, Mar 27, 2018 at 11:24 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 03/26/2018 11:23 PM, Carlos Bruguera wrote:
>
>> Hello everyone, I've been following the recent discussions on DID, and
>> more specifically DID-Auth. I haven't been able to join the calls since I'm
>> in a bit of an inconvenient timezone right now.
>>
>> I was just wondering to what degree is current discussion on this matter
>> taking into account Verifiable Credentials as part of the DID-Auth flow. If
>> my understanding is correct, I've only seen DID-Auth to cover the "proof"
>> process of DID ownership (or private key-ownership of an associated public
>> key pertaining to a DID). However, I can easily envision cases where the
>> authenticating party is requiring a certain set of (verified) attributes
>> linked (or owned) to the identity owner that corresponds to the DID being
>> authenticated. An example is simple "sign-up" on a website, where /name/,
>> /email/, /nationality/, and/or other personal attributes are to be
>> provided. If such sign-up process is being performed via DID-Auth, it makes
>> sense to re-use any claims that already attest for the validity of such
>> attributes, and these claims might be or might be not publicly accessible.
>>
>> Any thoughts or drafted ideas/diagrams on this regard? Does this make any
>> sense or maybe I'm missing something on the currently proposed DID-Auth
>> flow? In case DID-Auth gets to include the request and verification of
>> credentials as well, I think it should take into account public as well as
>> private credentials.
>>
>
> Markus covered this a bit in his response, but I wanted to give you
> links to the Credential Handler API which enables both DID-Auth and the
> exchange of Verifiable Credentials in the browser:
>
> Github: https://github.com/w3c-ccg/credential-handler-api
>
> Spec: https://w3c-ccg.github.io/credential-handler-api/
>
> Demo: https://credential-repository.demo.digitalbazaar.com/
>
> Video: https://www.youtube.com/watch?v=bm3XBPB4cFY
>
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
Received on Wednesday, 28 March 2018 03:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:25 UTC