]> Transmute

orie@transmute.industries

Security Internet-Draft cose jose transparency selective disclosure unlinkability untraceability When professionals travel for business, they carry identity documents, such as passports, employer related payment capabilites, such as corporate credit cards, and security keys that might be used for both personal or professional reasons, such as hotel or car keys. These credentials might be stored in a purse, briefcase or wallet. Digital storage systems struggle to support the various credential formats, physical proximity and remote presentation protocols, and assurance capabilities needed to enable international business. Device capabilities, cost and power consumption can preclude access and adoption of digital credentials, or exclude communities that require higher than normal privacy, sustainability, or availability guarantees. This specification describes a scalable solution to digital credentials, that is market friendly, transport agnostic, privacy oriented, and accountable to users of digital credentials above all other stakeholders. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials (spice) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The "Complaint tablet to Ea-nāṣir" is considered to be the oldest known written complaint. The tablet was written in Akkadian cuneiform, by a customer named Nanni to a merchant named Ea-nāṣir. The complaint describes how Ea-nāṣir had agreed to sell copper ingots to Nanni, via Nanni's unnamed servant, but the ingots were considered sub standard and were not accepted. Nanni created the complaint letter for delivery to Ea-nāṣir to explain that the copper was not the correct grade, that his servant was treated poorly, and that at the time of writing, he had not accepted the copper, but had paid for it. Search for the wikipedia article for the full story. Although humanity has moved on from clay tablets, to paper, to byte streams on the internet, some business challenges have remained the same. Travel is dangerous and expensive. The properties of the products we purchase, do not always match the properties that were advertised. There is a need to delegate negotiation to trusted intermediaries, while convincing counter parties that the intermediary is authorized to complete the transaction. There is a need to ensure that intermediaries do not tamper with the sale price or technical specification of the product. And there is a need to provide transparency regarding supply chain activities, so that consumers and businesses can make informed decisions regarding products and the known risks associated with them, as this information changes over time. If Nanni and Ea-nāṣir had transparency tokens, their trade would have been frictionless, and we would all be without the first written use case expressing the concept of credentials.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. To the best of our ability we reuse terminology from . For clarity, we provide more specific definitions when necessary.

principal:

A specific identity claimed by an entity when accessing a system.

identity:

The collective aspect of a set of attribute values (i.e., a set of characteristics) by which a system entity is recognizable or known.

identifier:

A data object -- often, a printable, non-blank character string -- that definitively represents a specific identity of a system entity, distinguishing that identity from all others.

issuer:

An entity that makes statements. Also known as issuing authority. This entity may have multiple identifiers.

statement:

A definite or clear expression of something; a judgement, opinion, attribute, predicate or proposition regarding a subject.

subject:

The entity being discussed, described or attributed. This entity may have multiple identifiers.

holder:

An entity which knows or possesses statements. This entity may have multiple identifiers.

verifier:

An entity which reviews, checks or confirms proofs and optionally statements. This entity may have multiple identifiers.

credential:

A token (usually an unforgeable data object) that is a portable representation of the association between an identifier and a unit of authentication information, or statement and that can be presented by a holder.

issued credential:

A tamper-proof object that includes a set of attributes about an entity issued by an issuing authority.

anonymous credential:

An issued credential that has privacy-preserving properties to enable data minimization and correlation resistance. RFC4949, deprecated this term, but recent advances in cryptography have changed the common understanding from what it once was.

credential proof:

An unforgeable data object derived from an issued credential, constructed by the holder of they credential

presentation:

The activity a holder performs when transmiting a credential proofs, and optionally issued credentials to a verifier.

notary:

Provides a trusted timestamp for a document, so that someone can later prove that the document existed at that point in time; verifies the signature(s) on a signed document before applying the stamp.

receipt:

A token (usually an unforgeable data object) proving that notarization has taken place.

counter signature:

A token (usually an unforgeable data object) proving that a second issuer, has seen a credential from a first issuer.

mediator:

A party that provides a transmission capability that protects the confidentiality or presentations made by holders.

Architecture

Credential Roles Credentials are essential to the efficient function of principals, be they natural persons or legal entities. Throughout their lifetime, a principal might create many identifiers, and these identifiers may be known to fulfill the various roles associated with digital credentials. These roles include being the issuer of statements about a subject, being the subject of statements made by issuers, holding credentials regarding identifiers for the principal, holding credentials regarding identifiers for other principals, presenting credentials to verifiers, or receiving presentations from other holders. The same entity may play all these roles, but for the sake of clarity we usually refer to interactions where each distinct entity playes a specific role in a workflow. The canonical example is: An issuer makes statements about a subject and produces an unforgable token as the issued credential. The issuer transmits the issued credential to a holder. A verifier requests a credential be presented. The holder derives a presentable form of the issued credential, called the presented credential. The holder transmits the presented credential to a verifier. There are auxillary roles which are special cases of the issuer, holder or verifier which are common in scenarious requiring additional assurance or confidentiality. In cases where the issuer, or holder lacks credibility, a countersignature or endorsement from a more reputatible entity might be required to convince a warry verifier. In cases where the issuer or holder might rotate verification keys frequently, or where the issuer or holder might not be well known to a verifier, a receipt from a notary can provide assurance to the verifier. | Statements || Envelopes | '----+-----' '-----+-----' | | '----. .-----' | v .------+------. | Credentials | '------+------' | +--------------+ .-' '-------------->+ Transparency | | .----------. | | Authority A --> | | Receipt 1 +<---+ Service 1 | | '---+------' +---------+----+ | | | | | +--------------+ .-' '------)---------->+ Transparency | | .----------. | | Authority B --> | | Receipt 2 +<------+ Service 2 | | '----+-----' +----+---------+ | | | | | '-. .--' | | | | | | | '-. .-' | | | | | v v v .-----+------. .---+-----+--. | Transparency | | Identity | | Tokens | | Documents | '-----+------' '------+-----' | | '-------. .-------' | | v v .-----------+---+--------. Verifiers --> \ Credential Proofs / '--------------------' ]]> In cases where a holder requires untraceability or is required to provide confidentiality regarding the provenance of a credential, delegation with or without attenutation to intermediate, or mediators holders, may be necessary. Notaries and mediators can leverage receipts and counter signatures to adjust the transparency, traceability and confidentiality associated with credentials. Giving unique and meaningful names to these roles, allows for digital trust systems to optimize for the properties that are most needed for credential use cases.

Identity Documents In order to verify a credential proof, verification material from the issuer and holder needs to be available at the time the verification algorithm is called. Resolving key material just in time negatively impacts privacy, security and performance. Whenever possible, it recommended to fetch verification keys and any associated metadata from a trusted source, and cache them locally. Key material can also be delivered out of band or in band depending on the envelope format used. This specification defines an identity document format based on transparency receipts that is compact, integrity protected, and can be delivered in band to verifiers in a network denied environment. This example is not normative. The identity document is a COSE Key, which has been signed and made transparent: The protected header includes identifiers for the entity, and the issuer of the identity document: Because the payload is opaque that content type can be used to support key formats that are present in IANA Media Types A verifier will need to discover or obtain the identity documents for the issuer and the holder. The identifier for the entity (issuer / holder) might be present in identifiers for resources representing the identity document for the identifier. This can be accomplished several ways. A verifier might discover an identity document through For example: A verifier might look up an identity document through a trusted key server, distributed database, or transparency service: In some cases, a verifier might require multiple receipts for an identity document, proving the same key information is bound to an identifier in multiple independent systems. The verifier can then decide to reject credential proofs from holder's that are unable to demonstrate enough transparency. During verification, the holder of a credential might be required to demonstrate possession of an identity document similar to A verifier can prepare a challenge token (signed nonce) or nonce for the holder. The holder can sign the challenge or nonce, along with an audience claim binding their response to the requesting verifier. This "key binding token" is defined similar to A credential requiring identity document confirmation (traceability, NOT unlinkability) can contain a cnf claim with an identifier that resolves to an identity document, and verifiers can confirm the associated key binding token is signed with the public key in an identity document for the holder. An example of a credential with identity confirmation: In order to verify credential proofs for this credential with identity binding, the verifier must:

• decode the protected header, and lookup the issuer identity document.
• confirm the issuer's identity document is still valid according to the verifier's policy
  • check the validity period, ensure the credential is not activated in the future or expired in the past.
  • check the status, in case the issuer of the issuer's identity docment has suspended or revoked the document.
  • check the key used to sign the credential proof, is present in the issuer's identity document.
• verify the credential proof with the issuer's public key, from their identity document.
  • decode the protected header, and validate the claims
  • lookup the holder's identity document using the hints inside the cnf claim
  • perform the same validation checks as were done for the issuer's identity document on the holder's identity document.
• verify the credential identity confirmation token using the holder's public key from the holder's identity document.
  • check the validity period, ensure the token is not activated in the future or expired in the past.
  • check the key used to sign the credential identity confirmation token, is present in the holder's identity document.

After these verifications and validations have been completed, if they have all succeeded the verifier should believe the following: The issuer's intention to assert the payload's relation to the subject has not been tampered with, the intention is still valid and has not changed since the credential was issued. The holder is in possession of the credential at the time of verification. The identity documents for both the issuer and holder are still valid. With these basics confirmed, the verifier can proceed to application / business layer processing of the payload. In the example above the payload is XML, and could represent some required legacy identity credential format. The verifier can then advertise that the legacy identity credential system is nearing end of life and that in order to support sustainability initiatives, reduce attack surface, and reduce carbon emmissions, only compact binary representations will be supported in the future. By keeping the payload opaque, transparency tokens can be intergrated into legacy systems that require larger and older media types, and assist those systems in modernizing to support compact binary.

Credential Principles Identification happens before we recognize threat or opportunity. Digital credentials are tools but like most tools, access and authority to use them are controlled by social, economic and political factors. Because this technology has the potential to adversly impact the freedom and inalienable rights of human beings, and healthy competition of legal entities, we state these principles of digital credentials, but caution that not all these properties can be easily achieved without sacrifice, and where some principles may be appropriatly degraded for legal entities, other principles ought to be preserved for natural persons.

Format Agility Modern paper credentials come in many different shapes and sizes, from notary stamped paper documents with wet ink signatures, to ASN.1 and X.509 signed XML documents representing commercial invoices. New formats are created to address the challenges and shortcoming of the formats that came before. Clay tablets were heavy, paper is easily destroyed, XML Signatures were expensive to compute and error prone, JSON while readable and writable by humans was wasteful of compute and storage when processed by machines. CBOR stands on the shoulders of giants, having benefitted from being created last, and suffering for being less well adopted than XML and JSON. It is natural to wish for there to be only one format, for digital credentials, as this would improve interoperability and reduce the costs associated with verifying credentials as part of business transactions, but nature does not produce discrete steps in technology deployment. Horses and automobiles shared the streets of cities in the early 19th century, and XML, ASN.1, JSON and CBOR will coexist so long as business requires them too. There are advantages to having multiple formats for digital credentials, particular when attempting to give privacy or security benefits to users that depend on specific protocols, that are only able to handle certain credential formats. For example, OAuth and OpenID Connect tend to require JSON claimsets and JWT credential formats. In order to preserve format agility, while leveraging existing claims and terminology, this document recommends a convention of preserving payload content as opaque bytes, leveraging protected headers to signature media types associated with validation of payloads, and claims in headers, in cases where format specific claims need to be consistently understood by verifiers.

Autonomy Issuers reserve the right to make statements. Holders reserve the right to present credentials. Verifiers reserve the right to reject presentation. Issuers may be subject to local, regional or global laws regarding statements. Holders might be denied service, if they are unwilling to present credentials. Verifiers might be subject to legal action for rejecting presentations in ways that violate local laws. When developing digital credential technology, consideration should be given to allow these roles to perform their function, with respect to local culture and conventions. Globally compelling behavior reduces the value of digital reputation over time, and degrades the ability of individual entities to provide better security and privacy properties, by applying least privledge and minimal disclosure.

Confidentiality All information should be considered sensitive, including timing, transmission metadata, the social graph that is built between issuers, subjects, holders and verifiers, and of course the content of statements. All encryption has a shelf life, these signals should be protected with cryptography appropriate for maintaining confidentiality for as long as is necessary to prevent harm.

Anonymity The act of observation changes the outcome, and character is what you do when nobody is watching. These technologies can be used to erode the abilty to create unlinkable digital identifiers, which are necessary for maintaining distinct digital identities. At the same time, these technologies can be used to create unlinkable digital identifers, which can be used in ways that are unpredictable. When designing digital trust systems, implementers should be cautious to preserve anonymity when it is essential,

Authenticity Perhaps the most essential property of digital credentials is assuring that statements can be made unforgable. Verifiers require this property to be able to make use of presentations from holders, with confidence that the holder is not able to tamper with or alter the statements made by issuers. This property also applies to the act of presenting by the holder. Assurance regarding the capabilities of the holder's device, or other evidence regarding the presence or awareness of the holder can be essential to convincing a verifier to accept a presentation. See FIDO, etc...

Transparency Transparency does not mean lack of confidentiality, it means commiting to be honest, in a way that dishonesty can be detected. This property is essential to service providers who maintain public key to identity bindings such as the work describes in key transparency. This property is also essential to statements about artifacts or ingredients that are assembled into more complex structures, so that is a problem in a sub component is detected, the potential damage can be mitigated, and the relying parties can be notified to protect their systems from cascading faults.

Accountability Of the various credential roles, holders and subjects are most vulnerable, and have the least power or incentive to adopt digital credential systems. Issuers and verifiers have great power and responsibility, and in cases where holders might not have the choices regarding credential storage, credential transmission, privacy and security features or the principles above, it will be due to the choices made by issuers and verifiers. Implementers should seek to frame the design of digital trust systems in terms of supporting the needs of holders, and challenged seek accountability to holders before all other parties.

Credential Workflows Credentials can be exchanged over differrent protocols. In this section we outline a few exemplar exchange scenarios, however, this list is not exhaustive and some protocols might define additional variations on these examples.

Credential Delivery A subject will request a credential be created by an issuer, or an issuer will create a credential for a subject. The next step requires the credential to be delivered to the subject, so they can become a holder, and make presentations to verifiers. This workflow is commonly referred to as credential delivery.

Presentation Delivery A holder will be challenged to present credentials to a verifier. It common for the verifier to specify the details of the credentials requested along with with nonce, to prevent replay attacks. The holder will craft a presentation for the verifier, possibly proving they control key material commited to be the issuer, by signing the nonce with a public key endorsed by the issuer. The holder will then transmit the presentation to the verifier. The verifier will check the signature from the issuer, the signature from the holder, and evaluate the nonce and other time related data to determine if the presentation is valid.

Credential Endorsement Some holders may request a counter signature on an existing credential. This can help convince a verifier who is not familiar with a given issuer.

Presentation Notarization Some holders may request a receipt from a notary when making presentations. This can help them prove that a notary, or intermediary offering notarization had accepted a presentaton in the past.

Credential Formats A credential format combines a well known and popular serialization, such as JSON or CBOR, with a well known and popular securing capability, such as JOSE and COSE. Different serializations offer benefits over each other, but some terminology is so consistently needed, that we see the same concepts emerging in each content type specific securing specifications. A good example is iss and sub which are popular in both JWT and CWT claims, and express the identifier of the issuer and the subject. Another is alg which expresses the cryptographic suite associated with providing the unforgable property of a credential. Another is nbf which expresses a time at which the statements made by the issuer become authoriative for the subject. Another is exp which expresses a time at which the statements made by the issuer cease being auuthoritative for the subject. Another is cnf which is a popular way to enable a holder to prove possession of a public key identity. Registries such as https://www.iana.org/assignments/cwt/cwt.xhtml and https://www.iana.org/assignments/jwt/jwt.xhtml over the ability for issuers, holders and verifiers to have unambious and well understood terminology, but they cannot scale to express all the possible statements about the possible subjects, in all the possible industry veriticals and contexts. Several competing solutions to this problem have emerged over time:

1. collision-resistant-names

In JSON, it is often recommended to prefix private claim names (names that are not registered), for example:

Example Collision-Resistant Name

In this scenario, since "is_root" is a private claim, and there is a risk that it might not be interpretted consistently, or that there might be collisions, since it is not registered, it is prefixed with a URL.

1. embedding type information

The JWT BCP recomments to use explict typing to avoid similar looking tokens from being confused, which could lead to faults in verification or processing. See section on explicit typing.

Example Explict Typing

1. embedding schema references

A schema language can help provide a clear, unambigious name for certain shapes of data, or certain properties of data. In JSON, this can be accomplished with JSON Schema, or JSON-LD:

Example Embedded Schema

Another solution is to leverage knowledge about the protocol to reduce the need to communicate redundant information, for example, if unicorn-protocol only uses JWT or only uses CWT, then signaling that a token is of these types is unnecessary. If the protocol grows to support new types in the future, a protocol specific parameter can be used remove ambiguity, or common solutions such as media types can be used to distinguish different kinds of statements and secure envelopes.

CBOR Web Tokens CBOR Web Tokens are defined in and extended to support selective disclosure in .

JSON Web Tokens JSON Web Tokens are defined in and extended to support selective disclosure in .

CBOR Web Proofs CBOR Web Proofs are defined in and extended to support credentials in this specification.

JSON Web Proofs JSON Web Proofs are defined in and extended to support credentials in this specification.

Transparency Tokens Transparency Tokens build on lessons learned from deploying JWTs, CWTs and attribute certificates.

Opaque Payloads A major structural difference between transparency tokens and previous token formats is the opacity of statements (the use of opaque payloads). Opaque payloads allow for arbitrary content to be easily integrated in statements, which enables issuers and verifiers to keep using serializations they are familar with, instead of mapping them to a new claims structure. For example, XML files can be signed and exchanged using JWS or COSE Sign 1 envelopes. Because transparency tokens secure payloads that are not required to be JSON objects or CBOR Maps, it is best to think of them as a new kind of token. Because the payload is opaque, it is common to play all the statement metadata in the protected header. In cases where selective disclosure or zero knowledge proofs need to be applied, this specification extends the related work to enable these capabilies over protected header metadata.

Detached Payloads Transparency Token also recommend support for detached payloads, this allows for easier integration with protocols that already transport well known content types, such as HTTP or file systems that support directory and file structures such as UNIX.

Redundant Claims In some cases, a JWT or CWT claim might be present in both the protected header and the payload. This can lead to protocol confusion vulnerabilities. The typ parameter MUST be used to distiniguish such tokens from similar looking tokens.

Key Discovery Editors note: consider moving out of scope. As a general rule, any well defined typ values SHOULD describe the available key discovery mechanisms. As a best practice the protected header should be the only location a verifier needs to look for hints related to discovering verification or decryption keys. The following fields are commonly used to discovery verification material: iss, kid, jwk, cnf.

Mutable Claims The unprotected header provides a useful extension point, but requires careful consideration, due to the lack of built in integrity checking. Common uses for the unprotected header include:

• adding counter signatures
• adding transparency receipts
• disclosing redacted commitments
• providing proofs of knowledge

Entity Identifiers JOSE and COSE have claims that are need to be text, but could be strings or URIs. Transparency tokens do not require these fields to be URIs. As a general preference, these fields should be a small as possible, and avoid transmitting information that is redundant to either:

1. the protocol specification (https can be ommmited when its known to be required...)
2. other protected claims (kid and sub can be relative to iss, if your typ says so...)

Trusted Hardware Application developers need the ability to communciate the assurances associated with a harware and software platform such as iOS and Android, so that issuers can have confidence in the key material that digital credentials will be bound too. In order to accomplish this, the app developer needs both RATS Evidence and a RATS Endorsement. By presenting both evidence and endorsement associated with a private key to an issuer, the issuer can be convinced that the digital credential store has the necessary security properties to hold high value credentials.

Architectural Alignment Transparency Tokens require some consistency in functionality between JOSE and COSE. Editors note: consider focusing only on COSE. In order to enable similar experience, while leveraging existing RFCs, the following structural changes and recommendations have been made. In cases where a break in conventions needs to be made, Transparency Tokens prioritize CBOR / COSE over JSON / JOSE.

Unprotected headers JOSE Compact and JSON serializations have been extended to support an unprotected header.

Claims in headers In JOSE, JWT claims go directly in the protected header.

Example JOSE Claims in Headers

In COSE, CWT claims go in the CWT Claims map, which is placed inside the protected header.

Example COSE Claims in Headers

Fully Specified Algorithms Parametric algorithms MUST NOT be used. Algorithms MUST exist in both JOSE and COSE registries, and have the same security properties to be suitable for Transparency Tokens.

Credential Forms In order to be a well recognized digital credential, there must be a specification defining the privacy and security properties of the format. The must be a registered media type which distinguishes the format from similar formats, for example: application/sd-jwt is different than application/jwt. There must be at least one way of extending the well known terminology associated with the credential format, to support industry use cases. The core operations of issuance, presentation and verification must be defined in a specification with privacy and security considerations. There must be clear definitions of the forms of credentials supported by the format, and the privacy and security considerations associated with each form.

Issued Credential This form is produced by an issuer and delivered to a holder.

Presented Credential This form is prepared by a holder and delivered to a verifier. In the simple case of credentials, this form is indistinguishable from the issued credential. In more privacy preserving forms, this from reveals a subset of the information commited to by the issuer, and possibly hides the identity of the subject in the process.

Privacy Considerations TODO Privacy

Collection limitation of attributes by Verifiers ## Holder consent for sending credential proofs to verifiers ## Unlinkability of credential proofs between Verifiers ## Untrackability of a credential proof by an Issuer ## Holder observability of both issued credentials and credential proofs ## Issuer anonymity among a set of Issuers

Security Considerations TODO Security

Binding of an issued credential to the correct owner ## Verification by a Holder that an issued credential matches with an expected object structure ## Verification by a Verifier that a credential proof matches with a supported object structure ## Binding of a credential proof to the correct owner ## Detection of collusion attacks between individuals ## Detection of the freshness or of the validity of a credential proof by a Verifier ## Binding of a credential proof to the intended verifier ## Prevention of the forwarding of a credential proof by a verifier to another Verifier

IANA Considerations This document has no IANA actions.

References Normative References LIP Fastly Cloudflare This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model that helps ensure the desired security and privacy goals are fulfilled. Mattr Self-Issued Consulting This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. Self-Issued Consulting Transmute This specification adds the equivalent of the JOSE typ (type) header parameter to COSE so that the benefits of explicit typing, as defined in the JSON Web Token Best Current Practices BCP, can be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. Transmute Fraunhofer SIT Microsoft Microsoft This specification describes verifiable data structures and associated proof types for use with COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Source for this draft and an issue tracker can be found at https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs. Ping Identity Ping Identity Self-Issued Consulting The JOSE set of standards established JSON-based container formats for Keys (https://datatracker.ietf.org/doc/rfc7517/), Signatures (https://datatracker.ietf.org/doc/rfc7515/), and Encryption (https://datatracker.ietf.org/doc/rfc7516/). They also established IANA registries (https://www.iana.org/assignments/jose/jose.xhtml) to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms. Authlete Microsoft Ping Identity This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. Spruce Systems, Inc. Authlete Inc. This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. mesur.io Transmute This document describes how to perform selective disclosure of claims withing a CBOR Web Token (CWT) [RFC8392] as well as how to create and verify those tokens. This document does not define any new cryptography. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK] JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

Examples These examples are "JOSE-like", because thats easier to generate than "COSE-like", however, they are designed to be easily translated to COSE. Editors note: There are currently no examples using BBS Blind Signatures, but we plan to add some when its easy to do so.

Presented Token with Receipts

Protected Header

Unprotected Header

JSON

Compact

Issued Token

Protected Header

Unprotected Header

JSON

Compact

Acknowledgments The following individuals provided input into the final form of the document:

• Ea-nāṣir
• Nanni
• Nis Jespersen