Re: Verifiable Credentials on DID-Auth

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>
wrote:

> 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
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>