This specification defines new proof format for use with Verifiable Credentials

In addition to meeting the requirements defined in [[RFC7515]]. We introduce some additional constraints to eliminate optionality and improve interoperability between implementations.

Introduction

Verifiable Credentials defines a JSON Web Token (JWT) proof format which requires the issuer and verifier to map JWT Registered Claim Names and the Verifiable Credentials Terminology.

This mapping process can be complex, and requires problematic operations such as type conversions for datetime fields. As a result of this complexity, this mapping can be implemented differently by issuers and verifiers which often leads to cases where to interoperability is not present, or unexpected security issues are introduced.

This specification introduces a (Content Type) Header Parameter that is used to define the content type for Verifiable Credentials that utilize JSON Web Signatures to provide signing and verification in a Verifiable Credential.

This approach, of utilizing to a (Content Type) Header Parameter to specify a discrete set of mappings and expected behaviors in translation between formats or representations of data is used commonly in other groups to secure arbitrary content using COSE and other document and data encoding formats. This approach is extensible to other data encodings and may be extended to provide a mechanism for use of CBOR encodings for Verifiable Credentials.

Producing

This specification uses normal approaches to the production and consumption of a JWS. For additional details, please see the full breakdown of the process in Producing and Consuming JWSs.

Specifically related to use of JWS with VCs the following normative requirements MUST be considered in production of a JWS.

• kid MUST be present in the JOSE Header.

  The value of kid MUST be one of the following:

  • An absolute DID URL that dereferences to a verification method with public key material in publicKeyJwk.

  • An relative DID URL that when combined with iss dereferences to a verification method with public key material in publicKeyJwk.

  • If kid is a relative DID URL in the JOSE Header, then iss MUST be present in the JOSE Header.

  • The publicKeyJwk is expected to verify the JWS.

• iss MAY be present in JOSE Header, and MUST match the controller of the dereferenced publicKeyJwk.

• alg MUST be present in JOSE Header, and MUST match the alg in the dereferenced publicKeyJwk.

• content type (cty) MUST be present in JOSE Header, and MUST be application/credential+ld+json.

• The JWS Payload MUST be a sequence of octets representing the UTF-8 JSON encoding of the credential.

Consuming

This specification uses normal approaches to the consumption of a JWS. For additional details, please see the full breakdown of the process in Producing and Consuming JWSs.

As a part of ensuring interoperability with VCs secured in the manner described in this specification, resolution of public key material must be considered, as a verifier may not have access to the public key.

In order to verify a Verifiable Credential using a JWS proof, the public key associated with the signature needs to be obtained. If the verifier does not already have the public key, it can be obtained through the following process:

• Decode the JOSE Header.
• Construct an absolute DID URL from the kid and iss if iss is present.
• Dereferences the absolute DID URL to obtain a verification method which contains a publicKeyJwk.
• Follow the process for Message Signature or MAC Validation.

Example

This is required for specifications that contain normative material.