From 1f574ef97578d999bae5735faa0ec11f70d084f7 Mon Sep 17 00:00:00 2001 From: wyc Date: Tue, 13 Jul 2021 18:59:17 -0400 Subject: [PATCH 1/6] Add PR review process for 2021 (#774) * Add PR review process for 2021. * Avoid GitHub id auto-linking. Co-authored-by: David I. Lehn * Update README.md Co-authored-by: Manu Sporny Co-authored-by: Manu Sporny Co-authored-by: David I. Lehn Co-authored-by: Brent Zundel --- README.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/README.md b/README.md index e6f0e30ab..6faaa9976 100644 --- a/README.md +++ b/README.md @@ -29,3 +29,33 @@ mailing list as well. ### Other useful links * [Public group email archive](https://lists.w3.org/Archives/Public/public-vc-wg/) + +## Process Overview for VC Data Model Pull Requests +1. For now, we will focus only on merging new errata PRs into this repository, +but encourage activity related to new features. +2. Once a PR is opened, chairs and editors make judgement call on whether +changes are substantive or editorial. +
+
Editorial
+
Mark with "editorial" tag, merge into branch "v1.1"
+
Substantive
+
Mark with "substantial" tag. Bugfixes are merged into separate branch "v1.2". New Features stay around as an open PR.
+
+3. W3C CCG is notified of PRs that will be merged in the next 14 days if there +are no objections. +4. When it's determined a new reccomendation should go out, the W3C Verifiable +Credentials Working Group members meet, review all the PRs that have been +merged, and make a formal recommendation if agreement is reached. + +### Roadmap for 2021 +- 1 editorial update (v1.1?) +- 1 substantive update (v1.2?) +- VC Test Suite Refactoring +- Start planning VC v2 Work, request a rechartering 3-6 months before end of + year to keep VC WG functioning. + +### Focus areas +- [v1] Fixing a specific bug +- [v1] Update examples in the spec to make them modern +- [v2] VC `@context` needs updating, possibly with security vocab modularized + into smaller components instead of all included into a large context file. From da7b669cbf7b718f12426bdaad7b7494607b420f Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Tue, 17 Aug 2021 09:41:47 -0700 Subject: [PATCH 2/6] Addresses #789 -- further documenting the holder in VC data model Signed-off-by: Stephen Curran --- index.html | 109 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 79 insertions(+), 30 deletions(-) diff --git a/index.html b/index.html index eb967034d..cca70c8fa 100644 --- a/index.html +++ b/index.html @@ -335,6 +335,9 @@

Ecosystem Overview

A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers. +Issuers can bind a verifiable credential to the holder to which it is issued, +and the holder can prove that binding using the proof property of a +verifiable presentation.
issuer
@@ -445,6 +448,10 @@

Use Cases and Requirements

verifiable presentation.
  • +Verifiable credentials are often bound by the issuer to a specific +holder at issuance time. +
    • +
  • Issuers can issue verifiable credentials about any subject.
  • @@ -1032,7 +1039,15 @@

    Concrete Lifecycle Example

    } } - +

    +In this example, the issuer has bound the verifiable credential to +the holder (Pat) using the +credentialSubject.id property (rather than using the +holder.id property). The second proof property in the +verifiable presentation (with proofPurpose of +"authentication") is used by Pat to prove their relationship to the +credentialSubject.id and thus, that they are the intended holder. +

    Implementers that are interested in understanding more about the proof mechanism used above can learn more in @@ -1946,9 +1961,13 @@

    Presentations

    • proof
    -If present, the value of the proof property ensures that -the presentation is verifiable. For details related to the use of -this property, see Section . +If present, the value of the proof property ensures that the +presentation is verifiable. Where the issuer has bound the +verifiable credential being presented to a specific holder, the +proof property +contains verifiable data to prove the indicated holder is +presenting the proof. For details related to the use of this property, see +Section .
    @@ -2070,6 +2089,10 @@

    Lifecycle Details

    any other actions involving a credential.
  • +In some cases, a holder might transfer to another holder one or more of its +verifiable credentials that have not been bound by the issuer to that holder. +
    • +
  • A holder might transfer one or more of its verifiable credentials to another holder.
    • @@ -2187,6 +2210,13 @@

    Trust Model

    entities.
  • +In many cases, the verifier trusts the issuer to issue each +verifiable credential to its intended holder (often the +subject) and, where appropriate, to provide a verifiable binding +in the +verifiable credential to that holder. +
    • +
  • The holder and verifier trust the issuer to issue true (that is, not false) credentials about the subject, and to revoke them quickly when appropriate. @@ -2931,7 +2961,7 @@

    Zero-Knowledge Proofs

  • Combine multiple verifiable credentials from multiple issuers into a single verifiable presentation without revealing -verifiable credential or subject identifiers to the +verifiable credential or holder identifiers to the verifier. This makes it more difficult for the verifier to collude with any of the issuers regarding the issued verifiable credentials.
    • @@ -3970,9 +4000,11 @@

    Identifier-Based Correlation

    Subjects of verifiable credentials are identified using the -credential.credentialSubject.id field. The identifiers used to -identify a subject create a greater risk of correlation when the -identifiers are long-lived or used across more than one web domain. +credential.credentialSubject.id field. Holders of +verifiable credentials are identified using the +credential.holder.id field. The identifiers used to identify a +subject and/or holder create a greater risk of correlation when +the identifiers are long-lived or used across more than one web domain.

    @@ -4035,10 +4067,10 @@

    Signature-Based Correlation

    Long-Lived Identifier-Based Correlation

    -Verifiable credentials might contain long-lived identifiers that could -be used to correlate individuals. These types of identifiers include -subject identifiers, email addresses, government-issued identifiers, -organization-issued identifiers, addresses, healthcare vitals, +Verifiable credentials might contain long-lived identifiers that could be +used to correlate individuals. These types of identifiers include +subject and holder identifiers, email addresses, government-issued +identifiers, organization-issued identifiers, addresses, healthcare vitals, verifiable credential-specific JSON-LD contexts, and many other sorts of long-lived identifiers.

    @@ -4181,9 +4213,8 @@

    Bearer Credentials

    Verifiable credentials that are bearer credentials are made -possible by not specifying the subject identifier, expressed using the -id property, which is nested in the -credentialSubject property. For example, the following +possible by not specifying either the subjectCredential.id or +holder.id identifiers. For example, the following verifiable credential is a bearer credential:

    @@ -4405,8 +4436,8 @@

    Usage Patterns

    subject across multiple presentations or verifiers. Even when different credentials are presented, if the subject identifier is the same, verifiers (and those with access to -verifier logs) could infer that the holder of the -credential is the same person. +verifier logs) could infer that the subject of the +credential is the same person. Likewise for holder identifiers.
  • The underlying information in a credential can be used to identify an @@ -4435,8 +4466,8 @@

    Usage Patterns

    • -Using a globally-unique identifier as the subject for any given -credential and never re-use that credential. +Using a globally-unique identifier as the subject and/or holder +for any given credential and never re-use that credential.
    • If the credential supports revocation, using a globally-distributed @@ -5026,19 +5057,23 @@

      Validation

      -

      Credential Subject

      +

      Holder

      -In the verifiable credentials presented by a holder, the value -associated with the id property for each -credentialSubject is expected to identify a subject to the -verifier. If the holder is also the subject, then -the verifier could authenticate the holder if they have -public key metadata related to the holder. The verifier could then -authenticate the holder using a signature generated by the holder -contained in the verifiable presentation. The id -property is optional. Verifiers could use other properties -in a verifiable credential to uniquely identify a subject. +An issuer may indicate that a verifiable credential has been +issued to a specific holder using the holder +property. Alternatively, when the holder is the subject, +the credentialSubject.id property could be used for the same +purpose, ideally paired with the nonTransferable property. +When such verifiable credentials are used to produce a verifiable +presentation, the +verifier may authenticate the holder (or holder subject) +using a holder-generated signature in the proof property of +the verifiable presentation. + +Where there is no issuer-designated holder the verifiable +credential can be transferred to other holders, and no holder +authentication is necessary by the verifier.

      @@ -5049,6 +5084,20 @@

      Credential Subject

      +
      +

      Credential Subject

      + +

      +In the verifiable credentials presented by a holder, the value +associated with the id property for each +credentialSubject is expected to identify a subject to the +verifier. The id property is optional. Verifiers +could use other properties in a verifiable credential to uniquely +identify a subject. +

      + +
      +

      Issuer

      From 89cd047c2f0e699a798c743632d3cacaffc407ad Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 26 Aug 2021 10:50:55 -0700 Subject: [PATCH 3/6] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index cca70c8fa..9dad81102 100644 --- a/index.html +++ b/index.html @@ -4467,7 +4467,7 @@

      Usage Patterns

      • Using a globally-unique identifier as the subject and/or holder -for any given credential and never re-use that credential. +for any given credential, and never re-using that credential.
      • If the credential supports revocation, using a globally-distributed From 2bf820fc4b59ebbd0d2d2a500f459e59ffffb598 Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 26 Aug 2021 10:51:16 -0700 Subject: [PATCH 4/6] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 9dad81102..dbeb1454e 100644 --- a/index.html +++ b/index.html @@ -448,8 +448,8 @@

        Use Cases and Requirements

        verifiable presentation.
      • -Verifiable credentials are often bound by the issuer to a specific -holder at issuance time. +Verifiable credentials are sometimes associated by the issuer with +a specific holder at issuance time.
      • Issuers can issue verifiable credentials about any subject. From 5afbe49d7e958e8e8660d41a35b3e2ec0ad52982 Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 26 Aug 2021 12:34:08 -0700 Subject: [PATCH 5/6] Update index.html Signed-off-by: Stephen Curran Co-authored-by: Manu Sporny --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index dbeb1454e..8f182dd58 100644 --- a/index.html +++ b/index.html @@ -4213,7 +4213,7 @@

        Bearer Credentials

        Verifiable credentials that are bearer credentials are made -possible by not specifying either the subjectCredential.id or +possible by not specifying either the credentialSubject.id or holder.id identifiers. For example, the following verifiable credential is a bearer credential:

        From 6cc2160a5b8a030fa6cddb5f3639f9817de02455 Mon Sep 17 00:00:00 2001 From: Stephen Curran Date: Thu, 26 Aug 2021 13:04:07 -0700 Subject: [PATCH 6/6] Update index.html Signed-off-by: Stephen Curran Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 8f182dd58..31b83fff3 100644 --- a/index.html +++ b/index.html @@ -5068,7 +5068,7 @@

        Holder

        When such verifiable credentials are used to produce a verifiable presentation, the verifier may authenticate the holder (or holder subject) -using a holder-generated signature in the proof property of +using a holder-generated signature in the proof property of the verifiable presentation. Where there is no issuer-designated holder the verifiable