W3C home > Mailing lists > Public > public-credentials@w3.org > April 2016

Verifiable Claims Use Cases Review

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 26 Apr 2016 23:04:20 -0400
To: Credentials Community Group <public-credentials@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
Message-ID: <57202C34.6070700@digitalbazaar.com>
Hi Shane, Dan,

Thank you for putting the abbreviated Verifiable Claims Use Cases
document together, it's looking good. I couldn't find any
significant/glaring errors.

This is a review of the Verifiable Claims Use Cases document that has
been paired with the Verifiable Claims Working Group Draft Charter:



> receiving digitally verifiable proof of attributes such as 
> qualifications and achievements

suggest changing to "digitally verifiable claims such as"

> The use cases in this document focus on concrete scenarios that the 
> technology defined by the group should address.

May want to change to:

"should address in part or in full".

There's a concern here that some of these use cases imply some sort of
browser API to be accomplished (which is true), but we're not trying to
do protocol in the first iteration of this WG.

Status of This Document

> This document represents a concise but limited collection of use 
> cases readers should review in conjunction with the proposed Charter
>  for a Verifiable Claims Working Group.

Again, we need some text that says we're specifically interested in the
data format and syntax portion of the use cases, not the protocol bits

We could re-write all of those use cases to just talk about data format
and syntax, but I'm afraid that if we do so, the use cases are going to
seem very strange and meta.


> The Verifiable Claims Task Force of the Web Payments Interest and

The missing "Group" at the end of "Interest" makes this sound a bit
awkward. Would rather:

The Verifiable Claims Task Force of the Web Payments Interest Group and
the Credentials Community Group at the W3C are investigating...

> This document does NOT attempt to define an architecture for the 
> support of Verifiable Claims.

We have an architecture, we should mention it at a high level either in
the use cases document or the Data Model document. Probably Use Cases is
a better place for it. Just a high level on credential issuers, holders,
repositories, and consumers/inspectors.

> by trusted parties

should this be "trusted third parties"?

How to Read This Document

The current text feels a bit overly prescriptive and patronizing. I
already know how to read, dammit! :P

I prefer a combination of this:


and this:


> basic operations that might be performed on a Verifiable Claim

Do we need to capitalize that? Probably just link to the terminology?
Although, we don't define "verifiable claim" in the terminology. We should.


Add "verifiable claim" to terminology section, make the definition
something like:

"A type of _claim_ such that the _issuer_ of the claim can be
cryptographically verified."

> A statement made by an entity about an identity.

I'd like to see if we can rip "identity" out of here and replace it w/

> credential consumer

The more I think about this the more I think we should rename it to
something else, like "inspector" (which is preferred by some of the ISO
/ ABC4Trust.eu projects). We will, of course, need to bikeshed this in
the VCTF and CG

> credential verification

We don't use this term anywhere in the document, strike it.

> identity

Let's get rid of this term if we can, it makes people think our scope is
bigger than it is. Lots of people also project a lot of their beliefs
onto the "identity" word.


> typical commerce situation.

strike "commerce" as the ecosystem is broader than that.

How a Verifiable Claim Might be Created

Change title of the section to "... Might be Issued"?

> #3 Verify identity

Let's do "verify a quality or attribute of Jane" instead. "Verify
identity" could mean a variety of things.

> steps 9 and 10

I'm not sure these steps add anything useful.

> Jane asks her User Agent to help her get a Verifiable Claim about
> her identity.

strike "identity"

> Her user agent connects her to a certificate issuer that is able to 
> verify her identity.

"certificate issuer" -> "credential issuer" or "claims issuer"

> information about her identity linked

Again, we want to distance ourselves from anything related to Identity
Proofing... maybe "information about her qualifications"

> she instructs her User Agent to save the Verifiable Claim

This makes it seem like the ecosystem depends on the UA - it doesn't, we
shouldn't make it seem like we need the browser to do anything in v1.

Again, steps #9 and #10 don't feel like they add much to the story.

3.2 How a Verifiable Claim Might be Used

> Verifiable Claims

We should link this to the terminology definition of "verifiable claim"

> (e.g., her passport, driving license, and birth certificate).

We're going to get push-back from privacy advocates that this is
over-sharing of information. Dial the credentials back to 3 proofs of
age from 3 different issuers (state government, school.

4. Use Cases

That Editor's note seems like it should be in red or some other color
that denotes it'll be removed eventually. Maybe this should be an issue

"Requirement" -> "Requirements" in the tables as some of the entries
have more than one.

4.1.1 Uniquitous Claim Issuance

"Uniquitous" -> "Ubiquitous"

> Asako just passed the final test to

This use case points out who the issuer and credential consumer are. I
think that's helpful. It may be repetitive to do it everywhere, but
maybe not? I'd like to try to work the mappings into the prose and see
what one of the sections looks like.

4.1.2 Credential Verifiability

Suggested change to Motivation section based on Editor's note:

> A credential that has been created by an issuer must be able to be 
> validated by an arbitrary third party (credential consumer).

Credentials are more valuable to society if almost anyone can verify
their authenticity to an extremely high degree of certainty.

> can be used to share her identity

can be used to assert her identity.

> and it is impossible to counterfeit.

"impossible" -> "effectively impossible"

4.2.1 Issuer Revokes Claim

> and are endorsing

This language is a loaded term of art in the education industry, we
should strike "endorsing" as it means different things to different people.

> an end user

client? customer? end user is bleh

> It was later discovered that BigTraining Co. was not actually 
> training anyone, and their organization's certificate was revoked via
> the US Department of Education's Accreditation Database.

This use case is technically very hard to achieve (I think?) and relies
on a CA-like system (maybe) and is not very realistic (maybe). We need a
replacement for this one, what about:

Jane took a college entrance exam at a local testing center and gets a
very high score. It is later discovered that Jane cheated on her test.
The local testing center revokes her credential and the revocation takes
effect immediately. Jane's credential is therefore invalid, and
prospective colleges will be aware of this when they check her

4.4.1 Credential Consumer Requests Credential

> Verifiable Claim

capitalized in some places, not in others. We should consistently
lowercase these terms (since they link to the terminology section).

> credentials to visible when

"to visible" -> "to be visible"


We should spell out what "MOOC" means

4.4.2 Consumer Verifies Claim

This section feels like it duplicates 4.1.2 Credential Verifiability

> The verifying entity must have the capability to connect the
> issuer’s identity to its credential identifier and the subject's
> identity to their identifier as indicated in the credential. The
> issuer’s verification information, such as its public key, must be 
> discoverable from the credential record and verifiably linked to the 
> issuer.

This is really hard to follow. Please consider simplifying it or
removing it entirely.

> well as one about Bob. iPharmacy's system automatically verifies the
>  ability of the physician to write prescriptions, as well as Bob's 
> insurance coverage.

It's not entirely clear that Bob handed over an insurance card
credential. Could we make that a bit more clear? For example:

"as well as Bob's electronic insurance card credential. iPharmacy's

4.4.3 Pseudo-Anonymity

> It also must be possible for the holder to limit the duration for 
> which that information is shared.

This is an impossible requirement (as data can be copied easily). We
could say something to the effect of "if the holder provides continuous
access to the information, they must also be able to revoke that access
at their discretion."

> He further marks the disclosure as expiring in 30 days - he does not
>  want his information verifiable after that time.

This is super important, and could be argued as out of scope. We should
keep it in there, it's important to keep this particular scenario in mind.

> assist her fellow countrymen.

change to "assist her fellow citizens."

Thanks for putting this short set of use cases together Shane, awesome
job as always. I'm going to make another pass through (at some other
point in time soon) and try to make sure that all of the findings on the
VCTF page wrt. benefits to ecosystem participants are there:


-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
Received on Wednesday, 27 April 2016 03:04:46 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:41 UTC