Re: Verifiable Credentials on DID-Auth

I'd say there are three possible "schools of thought" how DID Auth and a
Verifiable Credentials exchange protocol can relate to each other:

1. Keep them separate: You could argue that in the beginning of an
interaction between two parties, they need to authenticate (mutually, or
just in one direction). Then after this is done, you can initiate some
protocol for requesting and responding with Verifiable Credentials, so
the two parties can learn more about each other (and then perhaps make
authorization decisions).

2. Verifiable Credentials exchange is an extension to DID Auth. This is
how e.g. the Browser Credential Handler API or uPort are currently
architected. In this approach, proving control of an identifier, and
proving possession of Verifiable Credentials are not so different. If
you "only" want to prove control of an identifier, then that's a bit
like proving possession of "an empty list" of Verifiable Credentials.
The Verifiable Credentials are an "optional field" in the protocol.

3. DID Auth is a certain kind of Verifiable Credential. You can think of
DID Auth as an exchange of the most trivial Verifiable Credential
imaginable. A self-issued Verifiable Credential that states "I am me".
If you think about it this way, then the line between DID Auth and
exchange of "other" Verifiable Credentials is very vague, and both are
almost the same protocol.

I have picked my favorite approach in this list, let me know what's yours :)

Markus

On 03/27/2018 05:23 AM, Carlos Bruguera 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