- From: Carlos Bruguera <cbruguera@gmail.com>
- Date: Wed, 28 Mar 2018 10:08:24 +0700
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: public-credentials@w3.org
- Message-ID: <CAJrRL-GbZS+B4OHuxOuHnHPrFtms9NZLyTphn-ukM=gAB3=Yjg@mail.gmail.com>
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