Re: Questions about DIDs and Identity Credentials

I'm sure this topic has a long and painful history, and I hope I'm not
creating angst in bringing it up, but...

My understanding is that a Verifiable Credential contains Verifiable Claims
and that in some systems, a Verifiable Claim can be verified (proven)
independent from its Verifiable Credential container.  If so, I would think
that Verifiable Credentials are not the same as Verifiable Claims.

A story I was told is that the main reason the "Verifiable Claims" term
remains is that the Working Group was initially called "Verifiable Claims"
and it is hard to change that.

Is that not the case?

On Tue, Oct 2, 2018 at 10:35 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 10/02/2018 09:18 AM, Donghwan Kim wrote:
> > Hi there,
> >
> > First of all a lot of thanks for writing the specifications. The
> > followings are my questions about DIDs and Identity Credentials.
> >
> > 1. What is the difference or relationship between Identity Credentials
> > [1], Verifiable Credentials [2], and Verifiable Claims [3]? I haven't
> > read all the specifications thoroughly yet but they all seem to deal
> > with the same thing.
>
> They all refer to the same thing. The group has struggled with
> terminology and settled on "Verifiable Credentials".
>
> "Identity Credentials" was the precursor to "Verifiable Credentials", so
> it is just a historical document that eventually became "Verifiable
> Credentials". "Verifiable Claims" is another name for "Verifiable
> Credentials" and the link you provided refers to the use cases document
> that various specs (like the VC data model) are being created to support.
>
> >
> > 2. Is the Credential defined in 2. Terminology of the Identity
> > Credentials specification the same with one in the context of Credential
> > Management Level 1 [4]?
>
> No, it's not quite the *same* thing. There was an early effort to make
> it the same thing, but that effort has evolved to use layering instead.
> There is another spec that is being worked on to make Verifiable
> Credentials work with the Credential Management API. This spec is called
> the "Credential Handler API":
>
> https://github.com/w3c-ccg/credential-handler-api
> https://w3c-ccg.github.io/credential-handler-api/
>
> The goal of this spec is to enable third party Web applications (aka
> "digital credential wallets" or "credential repositories") to integrate
> with the Credential Management API to handle a variety of different
> kinds of credentials, including OpenIDConnect and Verifiable
> Credentials. This spec creates a "WebCredential" type that extends
> "Credential". This type of credential can be stored and retrieved using
> third party Web applications, using the browser as a mediator.
>
> A WebCredential is itself comprised of a specific type such as a
> "Verifiable Credential" and type-specific data -- which is defined in
> another spec, such as the VC data model specification.
>
> The Credential Handler API can also be used to replace NASCAR login
> forms on the Web for federated login with sites like
> Facebook/Google/Twitter with a simpler, targeted UX. Or it can be used
> to authenticate using a DID.
>
> > If so and everything goes well, I can store my
> > digital passport in the form of Credential defined in the terminology in
> > my mobile browser through navigator.credentials.store using some
> > Identity Provider, and use it to identify myself in other countries.
>
> Yes. This is a work item of the W3C Credentials Community Group. There
> is already a demo showing how this sort of thing can be achieved today
> through polyfills. The demo happens to use a "mock passport" as an example:
>
> https://credential-repository.demo.digitalbazaar.com/
>
> > Also, I can manage my credentials on my browser without installing 3rd
> > party app. Does it make sense?
>
> You would not need to install a third party app, but rather use a third
> party Web application. The "installation" of the third party Web
> application is really just a consent to grant permissions much like Push
> Notifications or allowing the browser to use your
> microphone/camera/geolocation. The user consents to allowing a third
> party Web application to store and provide credentials.
>
> Once the user has granted permission to a particular origin, that
> origin's Web application may appear in the browser's credential
> selection list when other relying party websites request
> "WebCredentials" of certain types, such as Verifiable Credentials.
>
> This approach mirrors the same approach that has been taken with Web
> Payments -- allowing third party Web applications to become wallets that
> handle payments on websites.
>
> >
> > 3. Needless to say, DIDs and Identity Credentials match perfectly with
> > blockchain environment. Is there any blockchain project that makes good
> > use of them?
>
> Yes, you're correct -- all three technologies, DIDs, Verifiable
> Credentials, and blockchain are designed to work well together. There
> are many projects and PoCs that are using them. For example, a couple
> that I am involved in are Sovrin (https://sovrin.org/) and a CBP PoC
> (
> https://www.supplychaindive.com/news/CPB-fail-fast-approach-blockchain/530936/
> ).
> There was also a mention on this mailing list related to all three
> technologies and testimony at the US Capitol:
>
> https://lists.w3.org/Archives/Public/public-credentials/2018May/0044.html
>
> I know a number of others on this list are also working on projects
> using these technologies together as well.
>
> Hopefully this information helps!
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
>

-- 

Stephen Curran
Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)


*Cell: (250) 857-109Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*