Re: Questions about DIDs and Identity Credentials

Thanks and my apologizes for bringing it up :-)

Yes - my use of "verified" was indeed not about the truth of the claim, but
rather about verifying the issuer of the claim, the holder of the claim,
whether tampered with, and (potentially) the revocation state of the
credential.

Agreed, my use of "independent" was not really appropriate as the
credential is needed for claim verification process.

Pheww...no change from what I had been thinking :-)

On Tue, Oct 2, 2018 at 2:03 PM Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 10/02/2018 02:23 PM, Stephen Curran wrote:
> > I'm sure this topic has a long and painful history, and I hope I'm not
> > creating angst in bringing it up, but...
>
> Yes, it does have such a history... and my view is that it would be best
> not to rehash it again. :)
>
> >
> > 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.
>
> The terminology "Verifiable Claims" was dropped because the claims
> themselves were *not* independently verifiable and because the
> terminology led to a confusion that a particular claim could be
> verified, i.e. the truth of that claim could be proven. That has never
> been the case with this work. What can be verified, through
> cryptography, is the *authorship* of one or more claims. Authorship can
> only be verified through the use of a "Verifiable Credential".
>
> Note: Whether or not the "original" Verifiable Credential (simple case)
> or a derived one with potentially fewer claims than the original
> (zkp/selective disclosure case) is used to prove authorship is a side
> matter.
>
> >
> > 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?
>
> Yes, the main reason that name remains is because it is hard to change
> it. If/when the working group recharters, changing the name may be on
> the table.
>
> >
> > On Tue, Oct 2, 2018 at 10:35 AM Dave Longley <dlongley@digitalbazaar.com
> > <mailto: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-109
> > Schedule a Meeting: //https://calendly.com/swcurran/
> >
>
>
> --
> 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>*

Received on Tuesday, 2 October 2018 21:16:21 UTC