Re: Verifiable Credentials on DID-Auth

As Markus mentioned we support 2.) in uPort. In almost all cases there is
some kind of information that is asked for, in particular for on-boarding.
In the case of an ethereum app that information could be as simple as an
ethereum address, in more traditional use cases name and email.

I'm also a bit confused about the difference between the authentication and
authorization for decentralized apps (and I've been working with http
authentication and authorization for 25+ years).

In most cases authorization is handled by your locally controlled key pair
accessing something on a blockchain or other decentralized resource. That
said we are not in a fully decentralized world yet, so we still need
authorization for certain kinds of endpoints. But in a fully decentralized
app, both are in some respects just a convenience for presenting a Web 2.0
like front end for a Web 3.0 like back end.

Many hybrid/regulated apps will also want to ask for Verified Credentials
as part of their Authentication flow, which complicates things a bit more
than the old http definition of 401 vs 403.

P



On Tue, Mar 27, 2018 at 9:09 AM, Dennis Yurkevich <dennis@mediaiqdigital.com
> wrote:

> 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
> <https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g>
> |
> <https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g>
>  London
> <https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g>
> |
> <https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g> WC1V
> 6RL
> <https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g>
>
> dennis@mediaiqdigital.com
> tel +44 (0)20 700 0420 | mobile +44 (0) 7794 597783 <+44%207794%20597783>
> [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
>



-- 
*Pelle Brændgaard // uPort Engineering Lead*
pelle.braendgaard@consensys.net
49 Bogart St, Suite 22, Brooklyn NY 11206
Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
Facebook <https://www.facebook.com/consensussystems> | Linkedin
<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter
<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>