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