Verifiable Claim

Full Title or Meme

A Verifiable Claim is one that can be Validated by a signed statement from some recognized authority as to the nature of a linkage between Attributes and a Subject.

Context

• The Context in which a validation applies should be made clear by a policy statement from the validating authorities. Note that validation is not required for a claim to be verified.
• The mission of the Verifiable Claims Working Group (VCWG) is to make expressing and exchanging credentials that have been verified by a third party easier and more secure on the Web.

Problem

Granting a benefit requires proof and verification. Some benefits demand a formal process that includes three parties. In this process, the holder asks for the benefit and the inspector-verifier grants or denies the benefit based on verification of the holder’s qualification from a trusted issuer.

False Claims

A Verifiable Claim can be perfectly constructed, totally verifiable, and still be completely false if it is not about a real attribute of the Subject that created the digital Identifier that is bound to the claim. This is a particularly knotty problem for a Decentralized ID that is not known to be bound to any particular human user by its very design. It may be that the Decentralized ID has protected the user against release of User Private Information, but it does not meet the primary meaning of Privacy, namely the right to be let alone. Now any can make a claim about any Identifier and if the Subject does not want to expose more of their User Private Information they cannot avail themselves of the right of Redress to false claims.

There are lots of statistics about (mostly unstructured) claims made on the web today, but the best estimate seems to be that over 50% are false. For example the claim that Hillary Clinton was running a pedophile ring out of the basement of a pizzeria that had no basement. Based on that finding it would be prudent to assume that 50% of the Verifiable Claims would also be false.

The science fiction writers Vernor Vinge and Stanislaw Lem have explored the hazards of navigating in the digital and the real worlds with false identities. In Vinge's book the protagonist is exposed and suffers from the hands of the corrupt government. In Lem's actual life he learns to create false papers and escapes from a corrupt government with the help of a false identity. It should be clear that as Identity papers become easier to create, the incidence of false papers will proliferate.

Solution

• A Verifiable Claims Data Model and Representations document is under development by the W3C Verifiable Claims working group on this GitHub site.
• It is hard to determine exactly what a verified claim is. It seems that it might only be verfied at the moment that a revocation check is made and not for one instant later, although that is not stated anywhere.
• There appears to be no way to link a verified claim to a user, or to prevent replay. It is not clear if all the members of the WG agree if that is the correct view.

Taxonomy from the spec

The terms used in the W3C Credential Community Group (CCG) are deliberately human oriented, whereas a Verifiable Claim is device (or service) oriented. As a result there is a conflict between the terms used in that group and this wiki.

Name in spec	Name in this wiki	Definition
entity	in conflict	A thing with distinct and independent existence such as a person, organization, concept, or device. A named object as opposed to a subject.
subject	subject	An entity about which claims may be made.
claim	attribute	A statement made by an entity about a subject.
verifiable claim	Statement	claim that is effectively tamper-proof and whose authorship can be cryptographically verified, expressed in a standard, machine-readable data format which can also be extended with minimal coordination.
entity credential	in conflict	A set of one or more claims made by the same entity about a subject. (unclear how this is different from a verifiable claim)
issuer	issuer	An entity that creates a verifiable claim, associates it with a particular subject, and transmits it to a holder. Examples of issuers include corporations, governments, and individuals.
inspector-verifier	Attribute Provider	An entity that receives one or more verifiable claims for processing. Examples of inspector-verifiers include employers, security personnel, and websites.
identifier registry	Identifier Provider	Mediates the creation and verification of subject identifiers. Examples of identifier registries include corporate employee databases, government ID databases, and distributed ledgers.
Entity Profile	Trusted Identifier	information that, together with a subject identifier id, constitute an entity profile. The properties are not claims and are not intended to be verifiable.
Issued	Date	This is the date, in string format, when the claim was issued. (unclear - see example)
Type	Software in use	Determine the location's expected behavior
revocation	theoretically impossible	The value of this property must be a revocation scheme that provides enough information to determine whether or not the credential has been revoked. (this sounds like an OCSP)

Note that the term Identifier or Attribute Provider is used in this wiki as the distinction between identifiers and attributes is arbitrary and subject to interpretation.

EXAMPLE - A simple verifiable claim

Note that it is unclear on which date the claim "over 21" is valid. It seems that the issued date applies to the original credential and not this derived credential. If it is the date on which the claim became true, then it is releasing too much information.

{
  "@context": "https://w3id.org/security/v1",
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  },
  "revocation": {
    "id": "http://example.gov/revocations/738",
    "type": "SimpleRevocationList2017"
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-18T21:19:10Z",
    "creator": "https://example.com/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "598c63d6",
    "signatureValue": "BavEll0/I1z … T24="
  }
}

JWT Rules for Verifiable Claims

This section was abstracted from the work of the Verifiable Claims working group of the W3C on 2019-06-01 and then modified to work for US Health Care needs. At that time this feature was at risk for removal from the spec for lack of implementations.

6.3.1 JSON Web Token

JSON Web Token (JWT) [RFC7519] is a widely used means to express claims to be transferred between two parties. Providing a representation of the Verifiable Credentials Data Model for JWT allows existing systems and libraries to participate in the ecosystem described in Section § 1.2 Ecosystem Overview. A JWT encodes a set of claims as a JSON object that is contained in a JSON Web Signature (JWS) [RFC7515] or JWE [RFC7516]. 

vc: JSON object, which MUST be present in a JWT verifiable credential. The object contains the verifiable credential according to this specification. 
vp: JSON object, which MUST be present in a JWT verifiable presentation. The object contains the verifiable presentation according to this specification. 

JWT Encoding

To encode a verifiable credential as a JWT, specific properties introduced by this specification MUST be encoded as standard JOSE header parameters, JWT registered claim names, or contained in the JWS signature part. If no explicit rule is specified, properties are encoded in the same way as with a standard verifiable credential, and are added to the vc property of the JWT. The following paragraphs describe these encoding rules. 
If the JWS is present, the digital signature either refers to the issuer of the verifiable credential, or in the case of a verifiable presentation, the holder of the verifiable credential. The JWS proves that the issuer of the JWT signed the contained JWT payload and therefore, the proof property can be omitted. 

alg MUST be used for RSA and ECDSA-based digital signatures. If only the proof attribute is used, the alg header MUST be set to none. 
kid MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, the kid can refer to a key in a DID document, or can be the identifier of a key inside a JWKS. 
typ, if present, MUST be set to JWT.

For backward compatibility with JWT processors, the following JWT registered claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts: 
exp MUST represent expirationDate, encoded as a UNIX timestamp (NumericDate). 
iss MUST represent the issuer property. 
iat MUST represent issuanceDate, encoded as a UNIX timestamp (NumericDate). 
jti MUST represent the id property of the verifiable credential. 
sub MUST represent the id property contained in the verifiable credential subject. 
aud MUST represent the subject of the consumer of the verifiable presentation. 


Example 27: JWT payload of a JWT-based verifiable credential using JWS as a proof (non-normative) 
{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "http://example.edu/credentials/3732",
  "iss": "did:example:abfe13f712120431c276e12ecab",
  "iat": "1541493724",
  "exp": "1573029723",
  "nonce": "660!6345FSer",
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiableCredential", "UniversityDegreeCredential"],
    "credentialSubject": {
      "degree": {
        "type": "BachelorDegree",
        "name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>"
      }
    }
  }
}
In the example above, vc does not contain the id property because the JWT encoding uses the jti attribute to represent a unique identifier. The sub attribute encodes the information represented by the id property of credentialSubject.

Example 29: JWT header of a JWT based verifiable presentation (non-normative) 
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1"
}
In the example above, the verifiable presentation uses a proof based on JWS digital signatures, and the corresponding verification key can be obtained using the kid header parameter. 
Example 30: JWT payload of a JWT based verifiable presentation (non-normative) 
{
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "aud": "did:example:4a57546973436f6f6c4a4a57573",
  "iat": "1541493724",
  "exp": "1573029723",
  "nonce": "343s$FSFDa-",
  "vp": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": ["VerifiablePresentation"],
    // base64url-encoded JWT as string
    "verifiableCredential": ["..."]
  }
}
In the example above, vp does not contain the id property because the JWT encoding uses the jti attribute to represent a unique identifier. verifiableCredential contains an string array of verifiable credentials using JWT compact serialization. 

References

• Synonyms include: Assurance Attested Corroborated.