Proposal: remove ambiguity and asymmetry as it relates to subject identifiers

[mistermoe]

i'd like to resurface a proposal @decentralgabe surfaced in #1130. He describes the issue at hand perfectly:

The current credentialSubject property is confusing for implementers and anyone inspecting a verifiable credential. It would be more meaningfully named claims, which makes it abundantly clear that the section is for the claims being made in the credential.

This issue is compounded with the current usage of the id property, which is an optional property within the current credentialSubject. There are two sources confusion here:

1. Needing to check for an optional property within a confusingly named credentialSubject property to learn whom the subject values are about (if they're about no one why are they there?)
2. Needing to understand that the id property is a special property with special processing rules which is identifying the party who the credential subject is about <--- this should be confusing enough for you to agree to rename the property.

So, I propose two changes:

Before

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

After

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "subject": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "claims": {
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

By elevating subject to a top-level property we follow the existing pattern used by issuer. We remove ambiguity about whom the credential is about. By renaming credentialSubject to claims we give a meaningful name to the property and remove confusion about its usage, including removing the need to parse its value for any special-case properties. Implementers will rejoice.

Caveats

The only thing that this breaks, as far as I am aware, is multiple subjects. I believe this can be handled like so...

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "NameCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "validFrom": "2010-01-01T00:00:00Z",
  "subject": ["did:example:ebfeb1f712ebc6f1c276e12ec21", "did:example:6f1c276e12ec21ebfeb1f712ebc"]
  "claims": [
    { "name": "Alice" },
    {  "name": "Bob" }
  ]
}

In addition to what @decentralgabe highlights, I see two primary issues:

1. Making subject identifier optional leaves too much room for ambiguity with respect to cryptographic verification of verifiable presentations. Ambiguity within such a crucial facet of Verifiable Credentials and Verifiable Presentations reduces the likelihood of interoperability which is in contradiction with the intent of standardization

2. There is asymmetry between issuer and credentialSubject specifically with respect to the fact that id is required for issuer but not credentialSubject.

this is especially confusing because the intent of an issuer identifier as described in the screenshot above is to provide a reliable means to access what's needed to verify the information presented in a credential. The same need exists when a subject presents a credential yet subject identifier remains optional

[TallTed]

The only thing that this breaks, as far as I am aware, is multiple subjects.

This comment suggests that you (@decentralgabe & @mistermoe) believe most verifiable credentials will contain claims about only one subject. I do not believe that is borne out by the use cases that drove VCDMv1 nor those that drove the updates to produce VCDMv2.

Even if only a minority of VCs will contain claims about multiple subjects, your suggested handling of those multiple subjects appears to break the association of each claim with its specific subject, which is vital.

  "subject": ["did:example:ebfeb1f712ebc6f1c276e12ec21", "did:example:6f1c276e12ec21ebfeb1f712ebc"]
  "claims": [
    { "name": "Alice" },
    {  "name": "Bob" }

How do you know whether "name": "Alice" or "name": "Bob" applies to "did:example:ebfeb1f712ebc6f1c276e12ec21" or "did:example:6f1c276e12ec21ebfeb1f712ebc"?

This forces us back to something like the following, which does not appear to me to be much if any improvement on the status quo --

  "subject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "claims": {
      "name": "Alice"
    }
    {
    "id": "did:example:6f1c276e12ec21ebfeb1f712ebc",
    "claims": {
      "name": "Bob"
    }
  }

---

Further, the question of subject identifier optionality. We originally decided to allow this because claims might be made about a pronoun a/k/a a blank node, identified indirectly by some subset of its attributes which are found among the claims in the VC. I've seen no argument that rebuts this justification.

This optionality does not mean that subject identifiers should never be included; it only allows for use cases where it is better to be omitted.

[decentralgabe]

I am wondering if this is something that should be handled by securing specifications. We could write language that requires a sub identifier in VC-JOSE-COSE, for example, that uniquely identifiers the credentialSubject.

[KendallWeihe]

...identified indirectly by some subset of its attributes which are found among the claims in the VC. I've seen no argument that rebuts this justification.

Does this pose a security concern? I'm sympathetic to the point that identification via a subset of attribution enables a more expressive & rich space for creation, but it may come at the cost of interop. Interop is only reasonable achievable with sufficient security guarantees, and we can't have standardized security over an amorphous set of identity attributes. I think @mistermoe articulates this well in the description:

Making subject identifier optional leaves too much room for ambiguity with respect to cryptographic verification of verifiable presentations. Ambiguity within such a crucial facet of Verifiable Credentials and Verifiable Presentations reduces the likelihood of interoperability which is in contradiction with the intent of standardization

@TallTed thanks for the response, I found that helpful! TIL what a pronoun is in the context of RDF! Perhaps I am still missing something?

[TallTed]

@KendallWeihe — Whether letting issuers "say anything about anything" (which was and remains a base design goal), including using blank nodes to identify the subject of any given VC, and whether a verifier relying on such statements, is a (problematic) security risk can only be evaluated by the issuers and verifiers in a given sphere of interaction. In other words, it falls into the verifier's "business logic," which is explicitly out of scope for the VCWG.

[KendallWeihe]

Thanks @TallTed I appreciate the clarity

[decentralgabe]

marking as pending closed, as I do not see this change reaching consensus in the group. what is possible is language adding to securing specifications. I have opened one such issue in vc-jose-cose here w3c/vc-jose-cose#242.

[brentzundel]

No objections raised since being marked pending close, closing