Re: Verifiable Credentials on DID-Auth

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

Received on Wednesday, 28 March 2018 19:13:19 UTC