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

Re: Verifiable Credentials on DID-Auth

From: Carlos Bruguera <cbruguera@gmail.com>
Date: Thu, 29 Mar 2018 09:01:06 +0700
Message-ID: <CAJrRL-HQFztpQWKX_qLTWDYm4ydE8EngPZcWfPuBh1VJT-HvOQ@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Hey Dave, thanks for your input.

This idea of ephemeral public key authentication is very interesting. Can
you expand on this a bit more? How will a temporary ownership of a public
key be done in the current DID / VC model? I'm suspecting that since it's
temporal, there's no actual modification made to the DID document that's
sitting on (assuming) a DID ledger, but the key is created/stored locally
on the user device, am I correct?. How is this case considered in current
DID Auth model being proposed? So far, unless I'm missing something, all
authentication is done against the DID document that is resolved from the
DID in question.

On Thu, Mar 29, 2018 at 2:12 AM, Dave Longley <dlongley@digitalbazaar.com>

> On 03/27/2018 11:08 PM, Carlos Bruguera wrote:
>> 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).
> #3 is actually how DID-Auth is done today through the Credential Handler
> API. Rather than signing an empty list of Verifiable Credentials, an
> on-demand Verifiable Credential is created and signed that merely
> asserts possession of a public key by a DID entity.
> One reason this approach was taken was because it also affords the
> opportunity for a third party (e.g. a cloud-based digital wallet
> provider) to instead create that Verifiable Credential, provided of
> course that they were previously delegated such authority. This enables
> assertion of ownership over a limited, temporary, ephemeral public key
> -- permitting login from internet cafes or other public terminals.
> We're not sure if this use case will continue to be supported in the
> future, it was designed many years ago when smartphone user penetration
> was much lower than it is today. We can have stronger security
> guarantees with other approaches now. But, I guess that is to say, doing
> DID-Auth, particularly over the Web, has been a consideration for quite
> some time.
> --
> Dave Longley
> Digital Bazaar, Inc.
> http://digitalbazaar.com
Received on Thursday, 29 March 2018 02:01:37 UTC

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