Verifiable Claims WG

TPAC Sessions

Day 1: Thursday October 25, 2018

Chairs: Matt Stone, Dan Burnett

Location: Saint Clair 1, Level 2 - Saint-Clair

1

Agenda: Thursday October 25

2

Welcome!

• Logistics
• IRC and Scribes
• W3C WG IPR Policy
• Introductions & Dinner
• Group mission, goals, scope, and background
• Agenda review

3

Logistics

• Location: Saint Clair 1, Level 2 - Saint-Clair
• WiFi: SSID “W3C-TPAC-2018”, pwd “lyon2018”
• Dial-in information: See next slide
• Restrooms: (out and to the right)
• Meeting time: 8am - 6pm CEST (2am-Noon EDT), Oct. 25-26
• Breaks: 10-10:30am, 12:30-1:30pm, 3:30-4pm
• TPAC Agenda: https://www.w3.org/2018/10/TPAC/schedule.html
• VCWG Agenda: https://tinyurl.com/TPAC2018VCWGAgenda
• Live slides: https://tinyurl.com/TPAC2018VCWGLiveSlides
• Dinner Details:
• Dinner reservation at 7:00pm at:
• Carré Royal, 16 Rue Royale, 69001 Lyon, France
• https://goo.gl/maps/wHWT1K4aW6x

​

​

4

IRC and Scribes

• Meeting discussions will �be documented
• Text Chat: �http://irc.w3.org/?channels=vcwg
• IRC:�http://irc.w3.org:6665/#vcwg
• Telecon info
• WebEx dial-in: +1-617-324-0000, 647 297 814
• More details (for members): https://lists.w3.org/Archives/Member/member-vc-wg/2018Oct/0006.html

5

W3C WG IPR Policy

• This group abides by the W3C patent policy�https://www.w3.org/Consortium/Patent-Policy-20040205
• Only people and companies listed at https://www.w3.org/2004/01/pp-impl/98922/status are allowed to make substantive contributions to the specs�(and yes, in this group we even treat +1s/-1s as contributions)
• Code of Conduct https://www.w3.org/Consortium/cepc/

6

Introductions & Dinner

• Introductions

​

• Expected count for dinner: 12-15
• Dinner proposals:
• Suggestions here (decide around lunchtime)
• See https://www.w3.org/2018/Talks/TPAC-2018/ready-set-go/Overview.html#eating

​

7

VCWG Mission and Goals

• It is currently difficult to express claims regarding education qualifications, healthcare data, banking account information, and other sorts of machine-readable personal information that has been verified by a 3rd party on the Web
• VCWG mission is to make expressing and exchanging claims that can be verified by a third party easier and more secure on the Web
• Our charter specifies that education related uses is our first focus but allows that other uses can be addressed such as digital offers, receipts, and loyalty programs and other areas if there is significant industry participation

VCWG Scope

• In Scope
• Recommend a data model and syntax(es) for the expression of verifiable claims, including one or more core vocabularies
• Create a note specifying one or more of these:
• How these data models should be used with existing attribute exchange protocols
• A suggestion that existing protocols be modified
• A suggestion that a new protocol is required
• Out of Scope
• Define browser-based APIs for interacting with verifiable claims. This work may be performed by a future Working Group if there is interest, but is not required for the Working Group to be successful
• Define a new protocol for attribute exchange. This work may be performed by a future Working Group if there is interest, but is not required for the Working Group to be successful
• Attempt to lead the creation of a specific style of supporting infrastructure, other than a data model and syntax(es), for a verifiable claims ecosystem
• Attempt to address the larger problem of "Identity on the Web/Internet"

​

What does that mean -- and what isn’t it?

Verifiable Credentials allow

• An issuing party to express a statement as a fact, ie “make a claim”
• A holding party to present the statement (in whole or in part) to a third party
• A verifying party to validate the statement hasn’t been tampered with

Verifiable Credentials DON’T

• Represent a “verified truth”

Documents and Background

• Home: https://www.w3.org/2017/vc/WG/
• Charter: https://www.w3.org/2017/vc/charter.html
• Primer: https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/verifiable-credentials-primer.md
• Polyfill Demo:
• Slide deck https://docs.google.com/presentation/d/1xhFUZkCo9QTpoB0SaIlon20mN0zM7U_3GLfMtw76DFo/
• Watch: https://www.youtube.com/watch?v=bm3XBPB4cFY

11

Agenda: Thursday October 25

12

Agenda: Friday October 26

13

Potential topics for “Open Topics” session

• TPAC Issues in GitHub (https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22)
• Schema issues. How does the verifier know which properties must be there, may be there, should not be there?

​

14

Getting to Candidate Recommendation

Time: 9:00-9:30

Leader: Chairs

15

Getting to Candidate Recommendation (30min)

Chairs

• Process Review (Dan 10min)
• Deliverable Review, Status, and Timing (Stone 10min)
• What are we missing? (Discussion 10min)

​

16

W3C Technical Report Progression Process (Dan)

• WD
• Does not imply consensus
• CR
• Entry - to publish as CR, the document is expected to be feature complete, have had wide review, and must specify the implementation requirements in order to exit
• Exit - to exit CR (and move to PR), the document must satisfy the stated implementation requirements; it must also not have made any substantive change not warned about upon entry
• PR
• Basically a one-month sanity check during which the AC is encouraged to have any final review and discussion, but if anything major happens it’s a fail (requiring a move back to CR or earlier)
• Recommendation - Done
• But errata are possible

17

https://www.w3.org/2017/Process-20170301/

Deliverable Review (Matt)

Recommendation Track

1. Verifiable Claims Data Model and Syntax (Recommendation)

​

WG Notes

• Verifiable Claims Use Cases & Requirements (WG NOTE)
• Verifiable Claims Privacy (WG NOTE)
• Verifiable Claims Implementation Guidance (WG NOTE)

18

Deliverable status (Matt)

• Verifiable Claims Data Model and Syntax (Recommendation)
• Stated success criteria from the Charter:
• The Working Group will develop test suites for Recommendation-track specifications.
• The group will seek evidence of independent interoperable uses of the vocabulary by at least two independent entities in the education sector. For example, academic qualifications (for a job application etc.).
• The group will undertake, in consultation with experts in security and privacy, a detailed analysis of threats to privacy, and techniques and practices for their mitigation.
• For any implementation cited to establish interoperability success, the Working Group will work with the Accessible Platform Architectures(APA) Working Group to help communicate accessibility issues to the developers.
• Status
• Nearly “Feature Complete”
• Issues: 39 open/active, 13 deferred = 26 issues

19

Deliverable status (Matt)

WG Notes

1. Verifiable Claims Use Cases & Requirements
• Nearly “Feature Complete”
• Discussion time in TPAC to review
• Issues: 34 open, including: 10 potential use case, 5 questions, 3 enhancements

​

• Verifiable Claims Privacy
• Privacy Considerations section in Data Model spec serves this purpose
• Will publish as an independent document

​

• Verifiable Claims Implementation Guidance
• Not started yet

20

Timing (Matt)

21

https://www.w3.org/2017/Process-20170301/

Big Audacious Goal for TPAC

Resolve all outstanding issues to support first CR in November �through PR, closure, or deferral

22

What are we missing? (Dan)

• For CR
• Test Suite
• What is preventing us from calling the specification ‘feature complete’?
• Scheduled discussion time at TPAC
• Terms of Use
• ZKP alignment
• This is the last chance to tell us about anything else other than those.
• Feature freeze is planned for Tue, Nov. 6.
• Post-CR
• Formal reviews
• Implementation reports

23

2018 Commercial Status Update

Time: 9:30-10:00

Leader: Manu

24

​

Verifiable Credentials

2018 - State of Adoption and Deployment

25

W3C Member Confidential

Education

26

W3C Member Confidential

Publishing

27

W3C Member Confidential

Financial Services

28

W3C Member Confidential

Insurance

29

W3C Member Confidential

Workforce

30

W3C Member Confidential

Trade and Logistics

31

W3C Member Confidential

All Supporting Organizations

32

W3C Member Confidential

Break

33

WCIG Joint Session

Time: 10:15-11:30

Leader: Manu Sporny

34

Joint WCIG Session

Location: Roseraie 3, Level 3 - Roseraie

WCIG Agenda: https://www.w3.org/WebCommerce/IG/wiki/Main_Page/FTF_Oct2018

• Progress on Verifiable Credentials (Dan Burnett - ConsenSys, Matt Stone - IE)
• Progress on Decentralized Identifiers (Kim Duffy - Learning Machine)
• Progress on WebAuthn + DIDs + VCs (Manu Sporny - Digital Bazaar)
• Credentials Community Group Roadmap (Joe Andrieu - Spec-Ops / Legendary Requirements, Christopher Allen - Spec-Ops / Blockchain Commons)
• Digital Offers (Linda Toth - Conexxus)

35

Use Case and Problem Domain Review

Time: 11:30-12:30

Leader: Joe Andrieu

36

Problem Domains (fka Needs Map)�https://w3c.github.io/vc-use-cases/

37

Problem Domains (fka Needs Map)�https://w3c.github.io/vc-use-cases/

Domain Check (20 min)

1. Additions
2. Are these the most relevant domains for implementers?
3. Are they in the right order?
4. Where do Curation & Web of Trust go?

38

Problem Domains (fka Needs Map)�https://w3c.github.io/vc-use-cases/

Within each domain (4 min ea):

• Are these the most relevant use cases for implementers?
• What is the most relevant use case from the current set?
• Do we have the most relevant use case?

39

Lunch

40

WCIG Joint Session: Digital Contracts

Time: 13:30-14:30

Leader: Allen Brown

41

Joint WCIG Session: Digital Contracts

Location: Roseraie 3, Level 3 - Roseraie

WCIG Agenda: https://www.w3.org/WebCommerce/IG/wiki/Main_Page/FTF_Oct2018

​

42

Open Issue Discussion

Time: 14:30-15:00

Leader: Chairs

43

Break

44

Threat Model,

Trust Model,

Security

Time: 15:30-16:30

Leader: Brent Zundel

45

Goals for this Session

W3C Verifiable Claims

46

Topics

​

• Interactive Whiteboard Session: Threat Model
• Review Trust Model (is it appropriate for the perceived threats)
• All other Security Concerns
• Prepare for Security Review

​

​

Requirements:

• Eager, talkative group
• Whiteboard
• Scribe, includes taking pictures of the whiteboard

W3C VC Trust Model (1 of 2)�

W3C Verifiable Claims

47

• Issuer: A role an entity may perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.
• Entity: A thing with distinct and independent existence such as a person, organization, concept, or device. An entity may perform one or more roles in the ecosystem.

• All entities trust the identifier registry to be incorruptible and to be a correct record of which identifiers belong to which entities
• The holder and the verifier trust the issuer to issue true (i.e., not false) credentials about the subject, and to revoke them quickly when appropriate.
• The holder trusts the repository to store the credentials securely, to not release them to anyone other than the holder, and to not corrupt or lose them whilst they are in its care.
• The holder trusts the verifier not to release the subject’s attributes to any third party without the holder’s consent

​

Credential has either:

OR

​

Transmission that clearly establishes that the issuer generated the credential.

• Credential was not tampered with in transit or storage.

1.

2.

W3C VC Trust Model (2 of 2)��

W3C Verifiable Claims

48

• The issuer and the verifier do not need to trust the repository.
• The issuer does not need to know or trust the verifier.�

Interactive Whiteboard Session: Threat Model

W3C Verifiable Claims

49

Dolev-Yao threat model for the communications between all the entities

• The verifier compromises the subject’s privacy
• The verifier does not obtain the correct public key of the issuer
• The VC wallet releases the subject’s VCs to unauthorised entities (privacy leak)
• The issuer makes false claims about the subject
• An attacker steals the VC wallet and uses the VCs (i.e. pretends to be the holder)

​

​

“Focal” Use Case and Threat Model (1 of 4)

From the Use Cases Document, https://w3c.github.io/vc-use-cases/

W3C Verifiable Claims

50

Use Case: International Travel with Minor and Upgrade

Malathi is traveling internationally with her 8-month-old son, Anand. His father, Rajesh, is staying home. Malathi has enough frequent flyer miles to upgrade the ticket to first class.

Upgrade

US passports do not establish relationship between parent & child

​

Credentials must be coordinated between two verifiers (travel agent and airline) for two individuals, and a digital coupon is used.

​

Travel Agent

at HappyAir

Airline

TSA

“Focal” Use Case and Threat Model (2 of 4)

​

W3C Verifiable Claims

51

International Travel with Minor and Upgrade

​

Verifiable Credentials

“Focal” Use Case and Threat Model (3 of 4)

​

W3C Verifiable Claims

52

International Travel with Minor and Upgrade

​

1. Threat: Stolen Key. Malathi steals Rajesh’s key in order to fake travel permission. (Kidnapping her kid and fleeing Rajesh.)
• Response: Rajesh could store his key with a trusted third party, such as an attorney.
• Response: Rajesh could use a hardware wallet with pin or biometric.
• Response: Rajesh could use a passphrase on his key
2. Threat: Stolen Key 2 Ticket purchaser has Malathi’s credentials, impersonating her to purchase a ticket. This could enable a third-party kidnapping.
• Response: Travel permission can be restricted to specific date and or trip minimizing abuse potential.
• Response: Embed identifying characteristics or biometric into the credentials so that verifiers can independently verify the subject in front of them is the subject in the credential.
• Response: Malathi could use a hardware wallet with pin or biometric.
• Response: Malathi could use a passphrase on her key
3. Threat: Impersonating traveler. Handled by identity assurance, using information within the credentials
• Response: Identity assurance based on the presentation, other data, beyond what is in the presentation & the claims.
• Response: Identity assurance based on the contents of the claims, potentially with enhanced data embedded in the claims, i.e., data not currently in passports, birth certificates, or marriage license. For example, a biometric template could be embedded in the birth certificate claim and that template could be used for interactive identity assurance at the time of submitting the presentation.

​

Threat Model

“Focal” Use Case and Threat Model (4 of 4)

​

W3C Verifiable Claims

53

International Travel with Minor and Upgrade

​

​

• ​
• ​
• ​
• Threat: False Parent Someone other than than Rajesh, e.g., Fred, signs the travel permission with a valid key, allowing Malathi to travel without Rajesh’s permission.
1. Response: Fred’s actions are fraudulent. Captured in signed statement, it would provide evidence for prosecution.
2. Response: Fred’s credentials won’t match those in Anand’s birth certificate. By comparing the credentials, HappyAir can prevent this attack
• Threat: Exposure of private information. By storing potentially compromising information in credentials and sending them over the network, we are increasing the attack surface for the subjects of those credentials.
• Response: Encrypt the claims (once by issuer, every verifier gets the same encrypted blob)
• Response: Encrypt the claims uniquely for each verifier. This may leak usage data to the issuer, assuming the holder must ask for a new, encrypted credential for each Verifier.
• Response: Blind the claims uniquely for each verifier.
• Response: Encrypt the presentation uniquely for each verifier. No issuer involved
• Threat: Stolen coupon Rajesh falsifies the upgrade coupon.
• Response: HappyAir signs the coupon with secure credentials.
• Response: Travel agent verifies the coupon through a distributed status registry, verifying it is still valid

​

Threat Model (continued)

What Does Tamper-Evident Mean?

W3C Verifiable Claims

54

“The cryptographic mechanism used to prove that the information in a verifiable credential or a verifiable presentation has not been tampered with is called a proof.

​

There are many types of cryptographic proofs including

• Digital signatures
• Zero-knowledge proofs
• Proofs of work
• Proofs of stake

Other Security Concerns

W3C Verifiable Claims

55

• TBD

Are We Ready for the Security Review?

W3C Verifiable Claims

56

• What will reviewers say?
• Prioritized list of items to resolve
• Next steps?

Test Suite Update

Time: 16:30-17:30

Leader: Ganesh Annan/Chris Webber

57

Test Suite slides from Chris, presented by Ganesh

https://dustycloud.org/misc/vc-test-suite.pdf

(Damnit, Chris!)

58

End of Day

59

Verifiable Claims WG

TPAC Sessions

Day 2: Friday October 26, 2018

Chairs: Matt Stone, Dan Burnett

60

Agenda: Friday October 26

61

ZKP Style/Spec Alignment

Time: 8:30-9:30

Leader: Brent Zundel

62

Agenda

• Brief recap of zero-knowledge proofs
• Discussion of existing pull requests
• PR-214 - Rename identifier registry
• PR-217 - Relationship of presentation and credentials
• And there’s more!

What is a zero knowledge proof?

Formally, a zero-knowledge proof must satisfy three properties:

• Completeness: if the statement is true, the honest verifier (that is, one following the protocol properly) will be convinced of this fact by an honest prover.
• Soundness: if the statement is false, no cheating prover can convince the honest verifier that it is true, except with some small probability.
• Zero-knowledgeness: if the statement is true, no verifier learns anything other than the fact that the statement is true.

ZKP Verifiable Credentials Ecosystem

Holder

Issuer

Verifier

Credential

Presentation

Verifiable Data Registry

(Public DID, Schema, Credential Definition, Revocation Registry)

Public Blockchain or other Decentralized Network

Signs Credential

Verifies Signatures

Wallet

Zero Knowledge Credential

Zero Knowledge Proof

Proof is not transferable

Supports selective disclosure

What this lets Sovrin do

1. Multiple credentials can be presented without sharing a common identifier.
2. Selective disclosure of claims.
3. After presentation, the Holder can’t be impersonated by the Verifier.

66

Objects that support Sovrin credentials

Revocation Registries

Credential Definitions

Schemas

Public DIDs

Pairwise DIDs can be gossiped and don’t belong on-chain.

​

Revocation cannot use unique identifiers or credentials become super-cookies.

​

Defining Credentials on-ledger allows you to present credentials anywhere and discover new opportunities for trust.

On-ledger schemas encourage credentials to converge on interoperable formats

Rename identifier registry

PR-214

The current registry for identifiers should also include:

• Schemas,
• Credential Definitions,
• Revocation registries

Proposal: Change this to “Verifiable Data Registry”

​

Rename identifier registry

PR-214

Rename identifier registry

PR-214

Presentation and its relationship to credentials

PR-217

The data model states:

​

​

​

The data from verifiable credentials are claims.�

A verifiable presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable. If credentials are directly presented, they become a presentation. Data formats derived from credentials that are cryptographically verifiable but that do not, of themselves, contain credentials, may also be presentations.

Presentation and its relationship to credentials

PR-217

For this reason we propose changing this image:

​

​

​

The aggregated claims in the verifiable presentation could come from multiple verifiable credentials.

Presentation and its relationship to credentials

PR-217

Propose adding selective disclosure paragraph to the 3.1 Claims section:

Presentation and its relationship to credentials

PR-217

along with this image:

Presentation and its relationship to credentials

PR-217

We also propose adding this paragraph to the 3.2 Credentials section

Presentation and its relationship to credentials

PR-217

We also propose changing this image of the basic components of a verifiable credential:

Selectively disclose all the things!

• On presentation, everything in the credential needs to be selectively discloseable
• Upon presentation, a Holder must disclose:
• At least one Issuer (one Who)
• At least one context/schema (one What)
• Everything else MUST be selectively discloseable:

​

​

• This supports the use of digital signatures that enable selective disclosure,
• But does not require them.
• Does the existing data model allow this?

​

What changes on presentation

{� "@context": "https://w3id.org/credentials/v1",� "id": "http://dmv.example.gov/credentials/3732",� "type": ["VerifiableCredential", "ProofOfAgeCredential"],� "issuer": "https://dmv.example.gov/issuers/14",� "expirationDate": "2020-01-01T19:73:24Z",� "claim": {� "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",� "birthDate": "1969-02-14" },� "proof": { ... }�}

One more thing . . .

• Some uses may require more than @context
• At credential definition time the issuer must commit to the data elements that can be included across all issued credentials (a fixed list)
• Sovrin zkp needs to know what is being signed:
• Schemas (which may fit under @context?),
• credential definitions,
• revocation registry links,
• And more . . . (Overlays, proof requests, and other things for version 2)
• Where should these reside?
• In the claim envelope?
• In the Claims section?
• In the Proof section?

​

​

What is signed cannot be modified

• The meaning of a credential must not change after issuance
• If the @context of a credential changes, the meaning of the credential changes
• External dependencies need to be immutable. I.e. they should be stored in a verifiable data registry.
• Otherwise they could change after issuance.

​

Issue 207: Rename Claim to Subject?

Time: 9:30-10:00

Leader: David Chadwick

81

Generic Claim Model

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Generic Claim Model

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Generic Claim Model

Transformed into JSON

​

{

“subject”: {

“property”: “value”

}

}

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Generic Claim Model

Transformed into JSON

{

"subject": {

"property": "value" } }

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Transformed into JSON-LD, subject is replaced by its ID

{

"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

"property": "value”

}

​

which causes a readability/understanding problem as there is no mention of “subject”. To whom does this ‘id’ belong?

Generic Claim Model

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Generic Claim Model

From the Data Model document

Claims are expressed using

subject-property-value relationships.

Transformed into JSON

{

"subject": {

"property": {

"object": {

"property": "value” } } } }

Transformed into JSON-LD

{

"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

"property": {

"id": "did:example:eb6f1c276e12ec21feb1f712eb",

"property": "value” } }

​

which again has readability/understandability problems

Combining the two

Value

Property1

Subject

Property2

Object

Value

Property3

Combining the two

Value

Property1

Subject

Property2

Object

Value

Property3

Transformed into JSON

{

"subject": {

"property1": "value",

"property2": {

"object": {

"property3": "value” } } } }

​

Transformed into JSON-LD

{

"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

"property1": "value",

"property2": {

"id": "did:example:eb6f1c276e12ec21feb1f712eb",

"property3": "value” } }

Application to Verifiable Credential Claims

1234

Identifier

Subject

has

Claim

21

Age

Transformed into JSON

{

"subject": {

"identifier": "1234",

"has": {

"claim": {

"age": "21” } } } }

This is perfectly readable and understandable JSON, whereas when is is transformed into JSON-LD

{� "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

”identifier": "1234",� "has": {� "id": "did:example:eb6f1c276e12ec21feb1f712eb",

"age": 21 } }

It is less meaningful, but is not even the current structure

RDF Subjects with type only

• Proof

"proof": { "type": "RsaSignature2018",…}

• Refresh Service

"refreshService": { "type": "ManualRefreshService2018", … },

• Question. Why is there no “id” property?

​

Current VC Data Model JSON

current JSON example

{

"claim": {

"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

"ageOver": 21

}

}

Claim

21

ageOver

1. This does not conform to the statement in the data model standard

“Claims are expressed using subject-property-value relationships.”

2. Causes confusion to readers who assume that
1. The claim is the subject, rather than the VC subject being the subject
2. The identifier is the ID of the claim, rather than the ID of the VC subject
3. Mixes up ownership. The id is determined by the subject, while the claim is determined by the VC issuer

did...21

id

Inconsistent use of JSON-LD

• To a person who understands JSON but not JSON-LD, the examples in the VC data model specification can be confusing
• What properties must every RDF subject have? “id”, “type”, both or neither?
• And to what do they refer?
• Whilst all the examples may be valid JSON and JSON-LD, the reader cannot intuitively determine what these properties mean or refer to as the following slides show
• Furthermore, a verifier’s code needs to know what properties a RDF subject should have, and to what they refer

RDF Subjects with type and id

• Verifiable Credential

{"id": "http://dmv.example.gov/credentials/3732", "type": ["VerifiableCredential", "ProofOfAgeCredential"],….}

• Credential Status

"credentialStatus": { "id": "https://dmv.example.gov/status/24, "type": "CredentialStatusList2017" },

• Verifiable Presentation

{ .. "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5”, "type": ["VerifiablePresentation"],…}

• Terms of Use

termsOfUse": [{ "type": "IssuerPolicy", "id": "http://example.com/policies/credential/4", …)

• Evidence

"evidence": [{ "id": "https://dmv.example.gov/evidencef2aeec97fc0d-42bf-8ca7-0..231",

"type": ["DocumentVerification"],..}

• Holder

"holder": { "type": "LawEnforcement”, "id": "did:example:ebfeb1276e12ec21f712ebc6f1c" },..}

• Parent

"parent": { "id": "did:example:ebfeb1c276e12ec211f712ebc6f", "type": "Mother" }

​

Questions

• Questions. How are the “type” values related to the encapsulating property?
• Is the RDF subject an instance of the encapsulating property?
• Is the “id” value the id of the type instance or the property instance?

95

RDF Subjects with an id only

• Claim

"claim": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",

…. },

• Disputed Claim

"disputedClaim": { "id": "did:example:ebfeb1f71…6e12ec21",

….}

• Questions. To what does the “id” refer?

RDF Subjects with neither

• Prohibition

"prohibition": [{ "assigner": "https://dmv.example.gov/issuers/14",….}

• Address

"address": { "streetAddress": "10 Rue de Chose",

• Questions. What determines whether an “id” is needed or not? How does a verifier determine what properties must or may be present for an RDF subject?

Morning Break

98

Terms of Use and Rights Discussion

Time: 10:30-11:30

Leader: David Chadwick, Chris Webber

99

Framing the conversation

• What do we agree on?
• VCs are verifiable credentials for making claims about entities
• Where do we disagree?
• Are VCs also an authorization framework? Or is it only for expressing “A says B about C”?
• Do Terms of Use allow us to express constraints on how the VC should or must be used?
• Are Terms of Use machine/system enforceable?
• How do we resolve this topic?

Are VCs an authorization framework?

• DC: Yes
• They are credentials, e.g. driving licence, passport, credit card, membership card, and follow the tradition of ABAC and RBAC, in which the issuer provides the user with a privilege (attribute or role in a VC), and the verifier determines which resources the user can access with this/these VCs
• CW: Not on their own
• An ACL/RBAC system can be built as a layer on top of VCs, but that shouldn’t happen in this spec
• Though other mechanisms exist separately (ocap-ld)
• Manu: Absolutely not (but can be layered on top?). (Also, authz framework not in our charter.)

101

Okay, so we agree that VCs can be used to build an ABAC/RBAC type authorization system. Is that substantially different from an ocap system?

• DC: No
• Both provide the same functionality i.e. allow Alice to access the verifier’s resources
• The ocap-ld effort is splitting effort; and only provides a subset of the functionality that VCs can provide.
• Users will expect to use VCs to access verifier’s resources, and indeed will use them in this way. Therefore we will miss an opportunity if we don’t deliver this functionality in V1 (Worse than that, we will provide security vulnerabilities - see later)
• CW: Yes
• The difference is well documented (called “equivalence myth” in ocap literature).
• In a sense it doesn’t matter if they are equivalent; VCs shouldn’t directly express access control, so whether ACLs and ocaps are the same can be a discussion for somewhere else
• Attenuation (caveats) in ocaps are much more constrained to whether permitting an action can pass/fail. This allows invocation algorithm to be boolean. Not possible if mixing in non-machine-enforceable constraints as in ToU.

Does the name “credential” imply authorization?

• DC: Yes
• The name “credential” itself is about authority or privilege. Issuing a VC is half of an ABAC/RBAC system
• We have already built effective authz systems using VCs.
• The verifier system administrator determines which access rights are granted to which credentials and configures this into the verification system (this is essentially what an ocap system does as well)
• CW: No, but it can be a path to it
• A CS degree is a credential but does not directly provide authority to administrate a server
• However, an employer evaluating Alice’s CS degree may decide she is qualified, and thus grant her the authority to administrate a server. This is a separate step, either marking in an ACL or issuing an ocap
• Don’t agree with equivalence assertion: ocaps provide a pass/fail algorithm for an action occuring. VCs can be used to express other things which *are not* “whether an action occurs”, such as “Alice says Bob has brown hair”. Want VCs to be used for access rights? Do it on another layer.

Are Terms of Use Mandatory to Enforce or Not

The value of this property ?MUST/SHOULD? be one or more terms of use that tell the verifier what actions it ?MUST/SHOULD? perform if it is to accept the verifiable credential or verifiable presentation. If the verifier is not willing to accept these terms of use then it ?MUST/SHOULD? reject the verifiable credential or verifiable presentation.

SHOULD OR MUST?

• DC:
• If SHOULD, then what are the conditions that apply when the verifier does not need to enforce the terms of use?
• It the terms of use should apply under all circumstances, then the standard should say MUST
• Clearly we cannot write conformance tests for every conceivable ToU (as we do not know what they are), but we can write them for a representative set
• CW:
• If we did MUST, how, for instance, would we write a test for the “don’t share” ToU? It would be impossible to detect sharing, and thus impossible to write a test. That’s a strong indicator. Anyone advocating MUST volunteers to write this test ;)
• We should not give users the illusion that merely attaching a ToU means it is guaranteed to be upheld.
• MUST moves into the realm of API

Are Terms of Use machine/system enforceable? (1/2)

​

How about some examples?

• Terms of Use say: “don’t share/store this information”, but the verifier violates the ToU and shares/stores it anyway
• Terms of Use say: “the VC must only be presented by the subject, and not by anyone else”, but the verifier accepts a VC presented by a different holder

Are Terms of Use machine/system enforceable? (2/2)

• CW: Issuer/subject have no system guarantee that the ToU will be observed
• That would require us defining not just a data model, but a protocol, which we agreed against
• Ideally we should be clear to users that ToU does not provide a technical guarantee to be upheld.
• If subject’s privacy is violated, do we say, “oops, guess that wasn’t a verifier, so spec never applied, you were wrong”?
• Enforcement can still happen OOB (eg terminate contract/service, lawsuit, loss of reputation)
• DC: System Enforceable is not the real issue.
• Some ToU are easy to enforce, others more difficult. But people can always break any system, even enforceable ones.
• The data model is essentially the protocol, as it defines the data that is to be transferred.
• Standards conformance is the real issue. The data model should specify the desired behaviour. Any implementation/verifier/holder that does not conform to the standard is outside the scope of the standard and therefore should not be considered (as CW is doing).
• The trust model is: the verifier is 100% trusted by the user, the holder 100% trusted by the issuer.
• If a holder/verifier doesn’t comply with the ToU, they can not be trusted, and they aren’t compliant with the standard, therefore they aren’t a conformant holder/verifier and should not be contacted by the issuer/holder.
• This does not stop enforcement from still happening OOB.

DC: Security Vulnerability

The original X.509 model had CAs issuing v1 PKCs to users, who obviously had their own key pairs. A v1 PKC did not differentiate between an end user and a CA.

Users soon found that they could issue their own PKCs to their friends, who could then authenticate to the same systems as themselves, as the verification software automatically processed the certificate chains.

This was fixed in v3 PKCs, by introducing the Basic Constraints extension that differentiated between end users and CAs.

If we do not build fields into v1 VCs that allow the issuer to place constraints on the issued VCs, then we will encounter similar vulnerabilities that X.509 v1 encountered, e.g. subjects with VCs will issue their own VCs that pass on their credentials to holders. Since the standard says that the holder is not always the subject, then the verifier cannot tell if this is OK or not, from the perspective of either the subject or the issuer.

CW: Security Vulnerability

We aren’t designing for a world with a privileged class of entities such as CAs, this is an open world system. A trust model where we expect trust in an entity is 100% in a circle or 100% out doesn’t work for this.

ACLs and ocaps aren’t equivalent and we shouldn’t pretend they are. Confused deputy vulnerabilities and ambient authority problems are well documented with ACLs, literature is widely available (eg “ACLs Don’t” paper).

DC. Note that OCAPs and VCs are equally vulnerable to confused deputy and ambient authority, since they depend upon the deputy not explicitly using only the credentials accompanying the request, rather than the type of the credential in the request.

VCs are useful for “A says B about C” interactions which are themselves not authority mechanisms. Whether or not to add an authority mechanism to VCs (as an ACL/RBAC type system) should be made separately, on a separate layer, with careful consideration of the security risks associated with such systems.

DC: Conclusion

We have to build minimum authorisation constraining fields into v1 VCs in order to tell verifiers how they have to behave. Examples include:

• Generic Terms of Use property - MUST obey
• Properties to constrain how VCs can be passed on by a subject �e.g. “Subject Only” specific Terms of Use
• Properties/procedures to say how a verifier can tell that a holder who is not the subject is the authorised holder.

CW: Conclusion

Terms of Use are useful. They can be used to describe expectations of issuer/subject/etc of what usage of this information is acceptable. Many core types of Terms of Use described in VCs cannot be protocol-enforced.

This too is part of the point: we are not defining a protocol.

It is absolutely possible to layer an authorization framework on top of VCs, which would be an ACL / RBAC type system. But that shouldn’t be the scope of this group, particularly because it requires solving many problems, and this group is running out of time.

Decisions, Next Steps

1. Terms of Use. The current text states MUST, but there is an outstanding issue whether to change this to SHOULD.
2. There is a “Subject Only” Terms of Use in the current spec, but this is marked “Readers should treat this entire section as at-risk and currently under debate.” So we need to decide whether to keep it or not, and if to remove it, what to replace it with (if anything).
3. There is a section (6.5.3.2) on Passing on a Verifiable Credential from a subject to another holder, but this is marked “The group is currently debating the best security model for delegation. Readers should treat this entire section as at-risk and currently under debate.” So we need to decide whether to keep it or not, and if we remove it, what to replace it with.

112

Joint meeting with PING

Time: 11:30-12:30

Leader:

113

Lunch

114

Future of VCWG Charter

Time: 13:30-15:00

Leader: Chairs

115

The Charter

• https://www.w3.org/2017/vc/WG/charter.html
• Expires: 31 March 2019

Options:

• Meet existing deadlines
• Extend Charter schedule
• up to 6 months max w/o AC review
• requires 3 mo. lead time
• Recharter with updated objectives
• Eg. introduce protocol
• AC review required

​

​

116

JWT and JSON-LD Industry Direction

Time: 15:00-16:00

Leader: Manu Sporny/ Christopher Allen

117

Orthogonal Issues in JOSE vs JSON-LD

• Tooling & Simplicity
• JOSE stack is well tooled, decent docs, lots of available middleware, has good hardware support. This suggests that it is proven and simple (but may not be — many in cryptographic community have concerns questions about security its algorithmic agility approach)
• JSON-LD stack tooling lacks diversity, is complex, and has no review of cryptographic layers, open hardware questions
• Tree vs Graph, Schema/Context
• JOSE stack works well with tree data models & closed world assumptions. Allows non-conformant metadata and “agile” development
• JSON-LD requires graph model knowledge & schema/context. Hard to just “dump into memory”. Graph model is hard to understand and do, for instance improper assumptions about “subject” and “id”. Also, “Don’t roll your own schema”. Hard to make schemas for non-conformant metadata that is ignored (or warned). Graph is just cryptographic hard at the edges.
• Readability / Developer Friendliness
• JOSE stack “looks” opaque, but offers relatively well understood use case.
• JSON-LD “looks” better, but complicated. More difficult to deeply understand. What what is signed in a graph model in memory is complicated.
• Canonicalization & Message Enveloping
• JOSE doesn’t require canonicalization, but requires you to preserve message envelope. Some issues with multiple signatures in graph.
• JSON-LD requires canonicalization, allows export/re-import of signed data
• Other
• Other graph model teams (non-JSON-LD) have issue with non-immutability of Schema/Context. Also quads not good enough (xdi, ipld)
• Questions in regards to more modern crypto (secp256k1, selective disclosure, multisigs) and JOSE
• Complaints about both using text vs compact binary blob

118

Progress on JOSE/COSE, JWTs, VCs Discussions

• Discussions at RWoT7
• Guidance and Standards for Interoperability of Decentralized Identity Systems
• JOSE/COSE
• CL Signatures
• Other parties
• IPLD
• Potential Paths Forward
• Use of JWK, COSE Key
• CL Signatures as COSE-encoded LD Signature Cryptosuite
• COSE-encoding for all signatures
• LD Proofs and LD Signatures use of COSE-encoding (using JWS today)

119

Break

120

Open Topics,

Close TPAC

Time: 16:30-EOD

Leader:

121

Open Topics (preference count)

• !Dog demo of ZKP Protocol using Sovrin (may not be available Friday).
• Practicality of stuffing real data into credentials (try HL7 FHIR Encounter or IMS Global Comprehensive Learner Record )
• TPAC Issues in GitHub (https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22W3C+TPAC+2018%22)
• Schema issues. How does the verifier know which properties must be there, may be there, should not be there?

122