Verifiable Credentials with JOSE (JWT) / COSE (CBOR)

Main

• [Working Draft] Securing Verifiable Credentials using JOSE and COSE 2023-09-08 Orie Steele, Michael Jones, Michael Prorock

  This specification defines how to secure credentials and presentations conforming to the VC-DATA-MODEL, with JSON Object Signing and Encryption (JOSE), and CBOR Object Signing and Encryption (COSE) RFC9052. This enables the Verifiable Credential data model [VC-DATA-MODEL] to be implemented with standards for signing and encryption that are widely adopted.

• [Editors Draft] Verifiable Credentials Data Model v2.0 2023-09-09

  Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential. Having and validating proofs, which may be dependent on the syntax of the proof (for example, using the JSON Web Signature of a JSON Web Token for proofing a key holder), are an essential part of processing a verifiable credential. At the time of publication, Working Group members had implemented verifiable credentials using at least three proof mechanisms:

  • Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE].
  • Securing Verifiable Credentials using Data Integrity Proofs [VC-DATA-INTEGRITY].
  • Camenisch-Lysyanskaya Zero-Knowledge Proofs [CL-SIGNATURES].

• Misinformation Stops Here: W3C VC 2.0 Supports JSON 2023-07-21 Kaliya Young

  There is one “extra” field that JSON-LD requires/needs which is @context and if you didn’t want to use it and simply wanted to ignore it and just do JSON you could. The VC would be entirely compliant and thus both data expression formats could live in the same specification. JSON-LD credentials that did have an @context that were being read by tooling that just did JSON could still read the credentials – it did nothing to interfere. This seems like a pretty good “let’s figure out how to live with each other” solution.

Verifiable Credentials with JSON Web Token (JOSE)

• Fully-Specified Algorithms for JOSE and COSE 2023-08-29 Mike Jones, Orie Steel; IETF

  This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being “fully specified”. Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being “polymorphic”. This specification creates fully-specified algorithm identifiers for all registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers.

• SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) 2023-05-26 IETF

  This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format [I-D.ietf-oauth-selective-disclosure-jwt].

• Native JWT Representation for Verifiable Credentials 2023-02-10 Mike Jones

  For the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable.

• Verifiable Credentials Deep Dive 2022-12-09 Pamela Dingle, Microsoft

  A JWT-VC has three parts, and the payload contains what I would call envelope information: the data needed to know who the credential is is bound to, who made the credential, when it was made and how it can be identified. Additionally, there is a JSON object called “vc”. Claims information is embedded inside the vc object. A JWT-VC uses an external proof, meaning in this case that signature data is not embedded inline with the credential, the signature is detached from the credential.

• Verifiable Credentials Flavors Explained 2021 CCI Kaliya ‘Identity Woman’ Young

  JWT takes a different approach to determining the meaning of claim terms in credentials. There is an IANA registry for JWT claims as a first place to look for JWT claim definitions. If the claim name isn’t in the IANA register, then the claim can be given a “give it a public name (i.e., a URI), [or] a local name (i.e., any string)”. The meaning of the terms is decided between the issuers and verifiers.

  In the VC Implementation Guidelines, there is a long list of the different characterizations of methods: JSON with JWT’s support vs JSON-LD with LD Signatures, Benefits of JWT, Benefits of JSON-LD and LD-Proofs.

• JWT vs Linked Data Proofs: comparing Verifiable Credentials 2020-05-7 Nader Helmy, Mattr

  JWTs have the benefit of already being widely used in today’s identity technologies, most notably in the framework used by OAuth 2.0 and OpenID Connect. Because of this, there are a number of existing software libraries and tools that developers can use immediately to begin building out their implementations. In addition, due to the fact that JWT-based credentials rely on a shared assertion format with existing identity technologies, it may be an easier mental model for newcomers to adopt when starting to experiment with VCs.

VC-JWT Selective Disclosure

• [Standards Track] SD-JWT-based Verifiable Credentials (SD-JWT VC) 2023-08-16 Oliver Terbu, Daniel Fett IETF

  JSON Web Tokens (JWTs) [RFC7519] can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.

  Selective Disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).

  SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures. However, SD-JWT itself does not define the claims that must be used within the payload or their semantics.

  This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload. Those Verifiable Credentials are called SD-JWT VCs.

• Selective Disclosure with SD-JWT 2023

  The purpose of this guideline is to document how to use SD-JWT with both versions V1.1 and V2.0 of the W3C Verifiable Credentials Data Model (VCDM). The document also covers application of these models in either JSON or JSON-LD format, and methods for protecting them using JWS signatures (compact or JSON serialised).

VC-JWT Presentation

• JWT VC Presentation Profile 2023-08-07 DIF

  The JWT VC Presentation Profile defines a set of requirements against existing specifications to enable the interoperable presentation of Verifiable Credentials (VCs) between Wallets and Verifiers.

  This document is not a specification, but a profile. It outlines existing specifications required for implementations to interoperate among each other. It also clarifies mandatory to implement features for the optionalities mentioned in the referenced specifications.

  The profile uses OpenID for Verifiable Presentations (OpenID4VP ID1) as the base protocol for the request and verification of W3C JWT VCs as W3C Verifiable Presentations (VC Data Model v1.1).

• [MDL, JWT-VC, LD-Proofs] OpenID for Verifiable Presentations 2022-12-30 OpenID

  This specification defines mechanisms to

  • request presentation of Verifiable Credentials in arbitrary formats.
  • provide a verifier with one or more Verifiable Presentations in a secure fashion.
  • customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].
  • combine the credential presentation with user authentication through [SIOPv2].
  • combine the credential presentation with the issuance of OAuth access tokens.

• Let’s (actually) Share Our Verifiable Credentials - Introducing the JWT VC Presentation Profile 2022-07-25 Jen Schreiber, Workday Technology

  In order to tackle the problem of how we actually share credentials, Workday teamed up with Microsoft, Ping Identity, and MATTR to develop a specification profile that outlines a list of standards and, once adopted by providers, would enable seamless verification of VCs. Development of the profile continues within the Decentralized Identity Foundation (DIF).

  In this blog post, we will give an overview of why specification profiles are required, what this profile involves, and what it means for the adoption of VCs.

VC-JWT Development

• [GitHub, NPM] did-jwt-vc 2023-09-04 DIF

  Create and verify W3C Verifiable Credentials and Presentations in JWT format

• [Web Tool] Transmute JSON Web Tokens into Verifiable Credentials

  Encoded PASTE A TOKEN HERE

• [Web Tool] JWT VC Interop Profile Microsoft

  Verifiable Credential Issuance and Verifier Sample

• [Web Tool] VC validator EBSI

  Validate a Verifiable Credential (VC) or a Verifiable Presentation (VP) using the @cef-ebsi/verifiable-credential and @cef-ebsi/verifiable-presentation libraries.

• [Spec v3] Open Badges Specification - JSON Web Token Proof Format 2023-09-08 Open Badges, IMS Global

  This proof format relies on the well established JWT (JSON Web Token) [RFC7519] and JWS (JSON Web Signature) [RFC7515] specifications. A JSON Web Token Proof is a JWT signed and encoded as a Compact JWS string. The proof format is described in detail in Section 6.3.1 “JSON Web Token” of Verifiable Credentials Data Model v1.1. That description allows several options which may inhibit interoperability. This specification limits the options while maintaining compatibility with [VC-DATA-MODEL] to help ensure interoperability.

• [GitHub] sd_jwt 2022-06-12 Kushaldas

  This is an implementation of the SD-JWT draft, revision 2.
  Do not use it in production yet.

• [GitHub] kotlin-did-jwt 2020-03-21 uPort Project

  The kotlin-did-JWT library allows you to sign and verify JSON Web Tokens (JWT) using ES256K, and ES256K-R algorithms.

JSON Web Proof

• [tracker] JSON Web Proofs / JSON Object Signing and Encryption (JOSE)2022-06-16 J. Miller, D. Waite, Ping Identity. M. Jones Microsoft. IETF

  The JOSE RFCs and JWT, have been widely adopted for identity use cases, including for the widely-deployed OpenID Connect protocol and STIR. Concurrent to the growth of adoption of these standards has been an increasing societal focus on privacy. Common privacy themes in identity solutions that intersect with JWT are user consent and minimal disclosure.

  In recent years, newer solutions have been evolving such as Verifiable Credentials that formalize the entities of Issuer, Holder, and Verifier. A Verifiable Credential lifecycle has three accompanying phases: issuance, storage, and presentation. The JOSE and JWT standards have also been adopted by Verifiable Credentials (for the JWT-VC representation), but JWS and JWT have limitations that make privacy protection challenging.

• JSON Web Proof (JWP) 2021-06-29 QuartzJer

  A JSON Web Proof (JWP) is very similar to a JWS, with the addition that it can contain multiple individual payloads instead of a singular one. New JWP-supporting algorithms are then able to separate and act on the individual payloads contained within.

• JSON Web Proof for Binary Merkle Trees 2021 O. Steele, Transmute. M. Prorock, mesur.io. Credentials Community Group

  The purpose of this specification is to define a generic encoding of merkle audit paths that is suitable for combining with [RFC7515] to construct selective disclosure proofs, that are not bound to the needs of certificate transparency, and that are suitable for more generic applications such as W3C Verifiable Credentials and W3C Decentralized Identifiers.

Verifiable Credentials with Concise Binary Object Representation (COSE)

• [Unofficial Draft] Verifiable Credentials with CBOR Object Signatures 2023-01-18 Transmute

  This specification introduces a (Content Type) Header Parameter that is used to define the content type for Verifiable Credentials that utilize CBOR Object Signing 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.

CBOR Explainer

• Why CBOR? 2022-12-07 Blockchain Commons

  we have decided to use the IETF CBOR (Concise Binary Object Representation) standard in our specifications, including Gordian Envelope.

  We chose CBOR as our serialization format choice for several key reasons

• [Working Group] Concise Binary Object Representation Maintenance and Extensions (cbor) 2023-06-07

  Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format.

• [W3C Editor’s Draft] CBOR-LD 1.0 - A CBOR-based Serialization for Linked Data 2022-09-06 Digital Bazaar,

  CBOR is a compact binary data serialization and messaging format. This specification defines CBOR-LD 1.0, a CBOR-based format to serialize Linked Data. The encoding is designed to leverage the existing JSON-LD ecosystem, which is deployed on hundreds of millions of systems today, to provide a compact serialization format for those seeking efficient encoding schemes for Linked Data. By utilizing semantic compression schemes, compression ratios in excess of 60% better than generalized compression schemes are possible. This format is primarily intended to be a way to use Linked Data in storage and bandwidth constrained programming environments, to build interoperable semantic wire-level protocols, and to efficiently store Linked Data in CBOR-based storage engines.

• [RFC 9052] CBOR Object Signing and Encryption (COSE): Structures and Process 2022-08

  Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

• [RFC 9053] CBOR Object Signing and Encryption (COSE): Initial Algorithms

  Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).

• Compact Credentials Mattr

  CBOR is a binary data format derived from JSON that allows it to utilizes data types like numbers, strings & arrays, however, due to being binary, it offers a much more compact message size. Often when CBOR is being discussed or documented, we can represent the data model using JSON to simplify the way the data can be viewed and modelled.

VC-CBOR Development

• [“mDL”,”eID”] The Developers’ Dilemma (why mdoc credentials) 2023-08-11 WaltID

  Though, as it is with many new technologies. Before they can reach the masses, they share a common trait: building with them is challenging and time-consuming, which is based on the lack of developer tools making usage easy and implementation quick.

  Which is why we build the mdoc lib, as an addition to our open-source identity stack. Proving our commitment to deliver on the latest developments in the industry. Offering tools that let you build compliant solutions across identity ecosystems using different identity flavors with ease, whether that be on- or off-chain identity like Tokens/NFTs, W3C Verifiable Credentials or now mdoc credentials. mdoc is a binary highly storage efficient credential format leveraging CBOR, standardized through ISO/IEC 18013-5:2021 mDL specification.

• @mattrglobal/vc-cwt-verifier NPMJS
  • Verify a credential
  • Verify a credential with a list of trusted issuers
  • Verify a credential skipping expiry and not before checks
  • Provide custom cache for issuer resolution