Re: Verifiable Credentials on DID-Auth

Great write up thanks for that Markus!

For me I would say #2 seems most intuitive.

D

On Tue, Mar 27, 2018 at 11:58 AM, Markus Sabadello <markus@danubetech.com>
wrote:

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


-- 
[image: Vital Design] <http://www.mediaiqdigital.com/>
Dennis Yurkevich
5th Floor | High Holborn House | 52-54 High Holborn | London | WC1V 6RL
dennis@mediaiqdigital.com
tel +44 (0)20 700 0420 | mobile +44 (0) 7794 597783
[image: Twitter] <http://www.mediaiqdigital.com> [image: Blog]
<https://www.facebook.com/MediaiQDigital> [image: Facebook]
<https://twitter.com/mediaiqdigital> [image: LinkedIn]
<https://www.instagram.com/mediaiqdigital> [image: Foursquare]
<https://www.linkedin.com/company/media-iq-digital-ltd> [image: Pinterest]
<http://www.mediaiqdigital.com/inspirethroughinsights>
*Disclaimer: *This email and its attachments may be confidential and are
intended solely for the use of the individual to whom it is addressed. Any
views or opinions expressed are solely those of the author and do not
necessarily represent those of Media iQ Digital Limited. If you are not the
intended recipient of this email and its attachments, you must take no
action based upon them, nor must you copy or show them to anyone. No
contracts or official orders shall be concluded by means of this email.
Please contact the sender if you believe you have received this e-mail in
error.

Media iQ Digital Limited is a company registered in England and Wales |
Company Number 07321732 | VAT No: GB995910763