R: Verifiable Credentials on DID-Auth

Hi Carlos,

I would take into account that claims expire, so it may make sense to re-present them at a second access.

A possible use case: I can access a site because I am the legal representative of company X. Two months later I am not the representative any more.



A second aspect: privacy requirements may make it convenient for the service not to store any claim…



Best,

--luca





Da: Carlos Bruguera <cbruguera@gmail.com>
Inviato: martedì 27 marzo 2018 10:40
A: Kyle Den Hartog <kdenhar@gmail.com>
Cc: public-credentials@w3.org
Oggetto: Re: Verifiable Credentials on DID-Auth



Thanks for your response, Kyle.

I can see the convenience in starting with the base case (DID-only auth) and then move into more complex possibilities. So I share that approach as well. However, I still don't see that particular case as one of authorization (or it's quite likely that I'm missing something from what authorization comprehends). Certainly the collection of multiple (verified) attributes by an authenticating party seems to only makes sense the first time the identity owner is "onboarded" into the particular service (just thinking of the conventional website sign-up flows).

Could you explain where does authorization fit in this workflow, and where can we draw the line between authentication and authorization on this regard? It seems to me the initial onboarding process to services using DIDs in addition to the exchange of certain credentials is going to be quite a common case.

Thanks,

Carlos



On Tue, Mar 27, 2018 at 3:17 PM, Kyle Den Hartog <kdenhar@gmail.com<mailto:kdenhar@gmail.com>> wrote:

   Hey Carlos,



   Thanks for your question as it is an important aspect to consider with regards to DID-Auth. This is something that we've considered, but ultimately had to move away from requiring. One reason for this is that we felt it fell into the category of authorization more often than authentication. Secondly, because we couldn't assume that all implementations of DIDs will use verifiable credentials, we elected to make this an optional addition that would be implemention (similar to how DIDs do with method specs) specific. With that said, I personally envision that a protocol such as TLS-flex will be able to encorporate authentication and authorization (e.g. using a VC to prove delegated authority) into the protocol, where they will seem as if they are all happening together because it's all happening within the TLS 1.3 protocol. I'd also guess there will also be other DID-auth method specs (seems like a fitting name to follow DID method specs) that will also use Verifiable credentials as well, so your ideas fall in line with what many others have been thinking. Does that help to clarify what you had in mind? Also, since you mentioned that you have difficulties making the calls, please add your comments and suggestions to the DID auth draft currently being worked on in the Spring 18 RWoT repo found here.



   https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md




   -Kyle DH



   On Tue, Mar 27, 2018, 1:32 AM Carlos Bruguera <cbruguera@gmail.com<mailto:cbruguera@gmail.com>> 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.


      Thanks beforehand.

      Regards,

      Carlos