jose J. Miller Internet-Draft D. Waite Intended status: Standards Track Ping Identity Expires: 20 March 2025 M. Jones Self-Issued Consulting 16 September 2024 JSON Web Proof draft-ietf-jose-json-web-proof-06 Abstract The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 March 2025. Miller, et al. Expires 20 March 2025 [Page 1] Internet-Draft json-web-proof September 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. JWP Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Registered Header Parameter Names . . . . . . . . . . . . 7 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . 7 4.1.2. "kid" (Key ID) Header Parameter . . . . . . . . . . . 7 4.1.3. "typ" (Type) Header Parameter . . . . . . . . . . . . 8 4.1.4. "crit" (Critical) Header Parameter . . . . . . . . . 8 4.1.5. "proof_jwk" (Proof JWK) Header Parameter . . . . . . 9 4.1.6. "presentation_jwk" (Presentation JWK) Header Parameter . . . . . . . . . . . . . . . . . . . . . . 9 4.1.7. "iss" (Issuer) Header Parameter . . . . . . . . . . . 9 4.1.8. "aud" (Audience) Header Parameter . . . . . . . . . . 10 4.1.9. "nonce" (Nonce) Header Parameter . . . . . . . . . . 10 4.1.10. "claims" (Claims) Header Parameter . . . . . . . . . 10 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 10 4.3. Private Header Parameter Names . . . . . . . . . . . . . 11 5. JWP Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Issued Form . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Issuer Protected Header . . . . . . . . . . . . . . . 12 5.1.2. Issuer Payloads . . . . . . . . . . . . . . . . . . . 12 5.1.3. Issuer Proof . . . . . . . . . . . . . . . . . . . . 12 5.2. Presented Form . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Presentation Protected Header . . . . . . . . . . . . 13 5.2.2. Presentation Payloads . . . . . . . . . . . . . . . . 13 5.2.3. Presentation Proof . . . . . . . . . . . . . . . . . 14 6. Serializations . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Compact Serialization . . . . . . . . . . . . . . . . . . 14 6.2. JSON Serialization . . . . . . . . . . . . . . . . . . . 15 Miller, et al. Expires 20 March 2025 [Page 2] Internet-Draft json-web-proof September 2024 7. Encrypted JSON Web Proofs . . . . . . . . . . . . . . . . . . 17 8. Detached Payloads . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.1. JSON Web Proof Header Parameters Registry . . . . . . . 19 10.1.1. Registration Template . . . . . . . . . . . . . . . 19 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 19 10.1.2.1. Algorithm Header Parameter . . . . . . . . . . . 19 10.1.2.2. Key ID Header Parameter . . . . . . . . . . . . 20 10.1.2.3. Type Header Parameter . . . . . . . . . . . . . 20 10.1.2.4. Critical Header Parameter . . . . . . . . . . . 20 10.1.2.5. Issuer Header Parameter . . . . . . . . . . . . 20 10.1.2.6. Audience Header Parameter . . . . . . . . . . . 20 10.1.2.7. Nonce Header Parameter . . . . . . . . . . . . . 20 10.1.2.8. Claims Header Parameter . . . . . . . . . . . . 21 10.2. Media Type Registration . . . . . . . . . . . . . . . . 21 10.2.1. Registry Contents . . . . . . . . . . . . . . . . . 21 10.2.1.1. The application/jwp Media Type . . . . . . . . . 21 10.2.1.2. The application/jwp+json Media Type . . . . . . 21 10.3. Structured Syntax Suffix Registration . . . . . . . . . 22 10.3.1. Registry Contents . . . . . . . . . . . . . . . . . 22 10.3.1.1. The +jwp Structured Syntax Suffix . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix B. Document History . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The JOSE specifications are very widely deployed and well supported, enabling use of cryptographic primitives with a JSON representation. JWTs [RFC7519] are one of the most common representations for identity and access claims. For instance, they are used by the OpenID Connect and Secure Telephony Identity Revisited (STIR) standards. Also, JWTs are used by W3C's Verifiable Credentials and are used in many decentralized identity systems. With these new use cases, there is an increased focus on adopting privacy-protecting cryptographic primitives. While such primitives are still an active area of academic and applied research, the leading candidates introduce new patterns that are not currently supported by JOSE. These new patterns are largely focused on two areas: supporting selective disclosure when presenting information and minimizing correlation through the use of Zero-Knowledge Proofs (ZKPs) in addition to traditional signatures. Miller, et al. Expires 20 March 2025 [Page 3] Internet-Draft json-web-proof September 2024 There are a growing number of these cryptographic primitives that support selective disclosure while protecting privacy across multiple presentations. Examples used in the context of Verifiable Credentials are: * CL Signatures (https://eprint.iacr.org/2012/562.pdf) * IDEMIX (http://www.zurich.ibm.com/idemix) * BBS signatures, described in [I-D.irtf-cfrg-bbs-signatures] * MerkleDisclosureProof2021 (https://github.com/transmute- industries/merkle-disclosure-proof-2021) * Mercurial Signatures (https://eprint.iacr.org/2020/979) * PS Signatures (https://eprint.iacr.org/2015/525.pdf) * U-Prove (https://www.microsoft.com/en-us/research/project/ u-prove/) * Spartan (https://github.com/microsoft/Spartan) All of these follow the same pattern of taking multiple claims (a.k.a., "attributes" or "messages" in the literature) and binding them together into a single issued token. These are then later securely one-way transformed into a presentation that reveals potentially only a subset of the original claims, predicate proofs about the claim values, or proofs of knowledge of the claims. | Editor's Note: This draft is still early and incomplete. There | will be significant changes to the algorithms as currently defined | here. Please do not use any of these definitions or examples for | anything except personal experimentation and learning. | Contributions and feedback are welcomed at https://github.com/ | ietf-wg-jose/json-web-proof (https://github.com/ietf-wg-jose/json- | web-proof). 2. Conventions and Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The roles of "issuer", "holder", and "verifier" are used as defined by the VC Data Model [VC-DATA-MODEL-2.0]. The term "presentation" is also used as defined by this source, but the term "credential" is avoided in this specification to minimize confusion with other definitions. Miller, et al. Expires 20 March 2025 [Page 4] Internet-Draft json-web-proof September 2024 2.1. Terminology The following terms are used throughout this series of documents: binding: A mechanism, indicated in an issued JWP, for how to verify a presentation was created by the intended holder. linkability: The property where multiple presentations may be correlated to a single issued JWP, either through consistency in the cryptographic integrity or due to particulars of JWP usage by an application. Such issued JWPs may be referred to as single-use, as multiple uses may leak unintended knowledge. unlinkability: The property of issuance and presentation algorithms and of application usage, where one presentation can only be correlated with other presentations based on holder-disclosed information. 2.2. Abbreviations * ZKP: Zero-Knowledge Proof * JWP: JSON Web Proof (this specification) * JPA: JSON Proof Algorithms [I-D.ietf-jose-json-proof-algorithms] * JPT: JSON Proof Token [I-D.ietf-jose-json-proof-token] 3. Background A _JSON Web Proof (JWP)_ is very similar to a JWS [RFC7515], with the addition that it can contain multiple individual secured payloads instead of a single one. JWP-supporting algorithms are then able to separate and act on the individual payloads contained within. The intent of JSON Web Proof is to establish a common container format for multiple payloads that can be integrity-verified against a cryptographic proof value also in the container. It does not create or specify any cryptographic protocols, multi-party protocols, or detail any algorithm-specific capabilities. To fully support the newer privacy primitives, JWP utilizes the three roles of issuer, holder, and verifier, as defined by the VC Data Model [VC-DATA-MODEL-2.0]. There are also two forms of a JWP: the issued form created by an issuer for a holder, and the presented form created by a holder for a verifier. The four principal interactions used by JWP are issue, confirm, present, and verify. Miller, et al. Expires 20 March 2025 [Page 5] Internet-Draft json-web-proof September 2024 A JWP is initially created by the issuer using the issue interaction. A successful result is an issued JWP that has a single issuer- protected header, one or more payloads, and an initial proof value that contains the issuing algorithm output. The holder, upon receiving an issued JWP, then uses the confirm interaction to check the integrity protection of the header and all payloads using the proof value. After validation, the holder uses the present interaction to apply any selective disclosure choices, perform privacy-preserving transformations for unlinkability, and add a presentation-protected header that ensures the resulting presented JWP cannot be replayed. The verifier then uses the verify interaction to ensure the integrity protection of the protected headers and any disclosed payloads, along with verifying any additional ZKPs covering non-disclosed payloads. While issue and confirm only occur when a JWP is initially created by the issuer, the present and verify steps may be safely repeated by a holder on an issued JWP. He resulting presented JWP is only unlinkable when supported by the underlying algorithm. Algorithm definitions that support JWPs are in separate companion specifications - just as the JSON Web Algorithms [RFC7518] specification does for JWS and JWE [RFC7516]. The JSON Proof Algorithms (JPA) [I-D.ietf-jose-json-proof-algorithms] specification defines how an initial set of algorithms are used with JWP. 4. JWP Header The members of the JSON object(s) representing the JWP Header describe the proof applied to the Protected Header and the Payload and optionally, additional properties of the JWP. The Header Parameter names within the JWP Header MUST be unique; JWP parsers MUST either reject JWPs with duplicate Header Parameter names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript]. Implementations are required to understand the specific Header Parameters defined by this specification that are designated as "MUST be understood" and process them in the manner defined in this specification. All other Header Parameters defined by this specification that are not so designated MUST be ignored when not understood. Unless listed as a critical Header Parameter, per Section 4.1.4, all Header Parameters not defined by this specification MUST be ignored when not understood. Miller, et al. Expires 20 March 2025 [Page 6] Internet-Draft json-web-proof September 2024 There are three classes of Header Parameter names: Registered Header Parameter names, Public Header Parameter names, and Private Header Parameter names. These requirements are intentionally parallel to those in Section 4 of [RFC7515]. 4.1. Registered Header Parameter Names The following Header Parameter names for use in JWPs are registered in the IANA "JSON Web Proof Header Parameters" registry established by Section 10.1, with meanings as defined in the subsections below. As indicated by the common registry, Header Parameters used in the Issued Form (see Section 5.1) and the Presented Form Section 5.2 share a common Header Parameter space; when a parameter is used by both forms, its usage must be compatible between them. These Header Parameters are intentionally parallel to those in Section 4.1 of [RFC7515]. 4.1.1. "alg" (Algorithm) Header Parameter The alg (algorithm) Header Parameter identifies the cryptographic algorithm used to secure the JWP. The JWP Proof value is not valid if the alg value does not represent a supported algorithm or if there is not a key for use with that algorithm associated with the party that secured the content. alg values should either be registered in the IANA "JSON Web Proof Algorithms" registry established by [I-D.ietf-jose-json-proof-algorithms] or be a value that contains a Collision-Resistant Name. The alg value is a case-sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations. A list of defined alg values for this use can be found in the IANA "JSON Web Proof Algorithms" registry established by [I-D.ietf-jose-json-proof-algorithms]; the initial contents of this registry are registered by [I-D.ietf-jose-json-proof-algorithms]. 4.1.2. "kid" (Key ID) Header Parameter The kid (key ID) Header Parameter is a hint indicating which key was used to secure the JWP. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the kid value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL. Miller, et al. Expires 20 March 2025 [Page 7] Internet-Draft json-web-proof September 2024 When used with a JWK, the kid value is used to match a JWK kid parameter value. 4.1.3. "typ" (Type) Header Parameter The typ (type) Header Parameter is used by JWP applications to declare the media type (#IANA.MediaTypes) of this complete JWP. This is intended for use by the application when more than one kind of object could be present in an application data structure that can contain a JWP; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when the kind of object is already known. This parameter is ignored by JWP implementations; any processing of this parameter is performed by the JWP application. Use of this Header Parameter is OPTIONAL. Per [RFC2045], all media type values, subtype values, and parameter names are case insensitive. However, parameter values are case sensitive unless otherwise specified for the specific parameter. To keep messages compact in common situations, it is RECOMMENDED that producers omit an "application/" prefix of a media type value in a typ Header Parameter when no other '/' appears in the media type value. A recipient using the media type value MUST treat it as if "application/" were prepended to any typ value not containing a '/'. For instance, a typ value of example SHOULD be used to represent the application/example media type, whereas the media type application/ example;part="1/2" cannot be shortened to example;part="1/2". The typ value jwp can be used by applications to indicate that this object is a JWP using the JWP Compact Serialization. The typ value jwp+json can be used by applications to indicate that this object is a JWP using the JWP JSON Serialization. Other type values can also be used by applications. It is RECOMMENDED that the typ Header Parameter be used for explicit typing, in parallel to the recommendations in Section 3.11 of [RFC8725]. 4.1.4. "crit" (Critical) Header Parameter The crit (critical) Header Parameter indicates that extensions to this specification and/or [I-D.ietf-jose-json-proof-algorithms] are being used that MUST be understood and processed. Its value is an array listing the Header Parameter names present in the JWP Header that use those extensions. If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWP is invalid. Producers MUST NOT include Header Parameter Miller, et al. Expires 20 March 2025 [Page 8] Internet-Draft json-web-proof September 2024 names defined by this specification or [I-D.ietf-jose-json-proof-algorithms] for use with JWP, duplicate names, or names that do not occur as Header Parameter names within the JWP Header in the crit list. Producers MUST NOT use the empty list [] as the crit value. Recipients MAY consider the JWP to be invalid if the critical list contains any Header Parameter names defined by this specification or [I-D.ietf-jose-json-proof-algorithms] for use with JWP or if any other constraints on its use are violated. When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWP Protected Header. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations. 4.1.5. "proof_jwk" (Proof JWK) Header Parameter The proof_jwk (Proof JWK) represents the public key used by the issuer for proof of possession. This key is represented as a JSON Web Key public key value. It MUST contain only public key parameters and SHOULD contain only the minimum JWK parameters necessary to represent the key; other JWK parameters included can be checked for consistency and honored, or they can be ignored. This Header Parameter MUST be present in the JWP issuer header parameters and MUST be understood and processed by implementations. 4.1.6. "presentation_jwk" (Presentation JWK) Header Parameter The presentation_jwk (Presentation JWK) represents the public key used by the holder for proof of possession. This key is represented as a JSON Web Key public key value. It MUST contain only public key parameters and SHOULD contain only the minimum JWK parameters necessary to represent the key; other JWK parameters included can be checked for consistency and honored, or they can be ignored. This Header Parameter MUST be present in the JWP issuer header parameters and MUST be understood and processed by implementations. 4.1.7. "iss" (Issuer) Header Parameter The iss (issuer) Header Parameter identifies the principal that issued the JWP. The processing of this claim is generally application specific. The iss value is a case-sensitive string containing a StringOrURI value. Its definition is intentionally parallel to the iss claim defined in [RFC7519]. Use of this Header Parameter is OPTIONAL. Miller, et al. Expires 20 March 2025 [Page 9] Internet-Draft json-web-proof September 2024 4.1.8. "aud" (Audience) Header Parameter The aud (audience) Header Parameter identifies the recipients that the JWP is intended for. Each principal intended to process the JWP MUST identify itself with a value in the audience Header Parameter. If the principal processing the Header Parameter does not identify itself with a value in the aud Header Parameter when this Header Parameter is present, then the JWP MUST be rejected. In the general case, the aud value is an array of case-sensitive strings, each containing a StringOrURI value. In the special case when the JWP has one audience, the aud value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Its definition is intentionally parallel to the aud claim defined in [RFC7519]. Use of this Header Parameter is OPTIONAL. 4.1.9. "nonce" (Nonce) Header Parameter The nonce (nonce) Header Parameter is a case-sensitive string value used to associate protocol state with a JWP. This can be used, for instance, to mitigate replay attacks. The use of nonce values is generally protocol specific. Its definition is intentionally parallel to the nonce claim registered in the IANA "JSON Web Token Claims" registry (#IANA.JWT.Claims). Use of this Header Parameter is OPTIONAL. 4.1.10. "claims" (Claims) Header Parameter The claims Header Parameter is an array listing the Claim Names corresponding to the JWP payloads, in the same order as the payloads. Each array value is a Claim Name, as defined in [RFC7519]. Use of this Header Parameter is OPTIONAL. 4.2. Public Header Parameter Names Additional Header Parameter names can be defined by those using JWPs. However, in order to prevent collisions, any new Header Parameter name should either be registered in the IANA "JSON Web Proof Header Parameters" registry established by Section 10.1 or be a Public Name (a value that contains a Collision-Resistant Name). In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Header Parameter name. New Header Parameters should be introduced sparingly, as they can result in non-interoperable JWPs. Miller, et al. Expires 20 March 2025 [Page 10] Internet-Draft json-web-proof September 2024 4.3. Private Header Parameter Names A producer and consumer of a JWP may agree to use Header Parameter names that are Private Names (names that are not Registered Header Parameter names Section 4.1 or Public Header Parameter names Section 4.2.) Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution. 5. JWP Forms A JWP is always in one of two forms: the issued form or the presented form. A structural difference between the two forms is the number of protected headers. An issued JWP has only one issuer protected header, while a presented JWP will have both the issuer protected header and an additional presentation protected header. Each protected header is a JSON object that is serialized as a UTF-8 encoded octet string. All JWP forms have one or more payloads; each payload is an octet string. The payloads are arranged in an array for which the ordering is preserved in all serializations. The JWP proof value is one or more octet strings that are only meant to be generated from and processed by the underlying JPA. Internally, the proof value may contain one or more cryptographic statements that are used to check the integrity protection of the header(s) and all payloads. Each of these statements may be a ZKP or a traditional cryptographic signature. The algorithm is responsible for how these statements are serialized into a single proof value. 5.1. Issued Form When a JWP is first created, it is always in the issued form. It will contain the issuer protected header along with all of the payloads. The issued form can only be confirmed by a holder as being correctly formed and protected. It is NOT to be verified directly or presented as-is to a verifier. The holder SHOULD treat an issued JWP as private and use appropriately protected storage. Miller, et al. Expires 20 March 2025 [Page 11] Internet-Draft json-web-proof September 2024 5.1.1. Issuer Protected Header The issuer protected header applies to all of the payloads equally. It is recommended that any payload-specific information not be included in this header and instead be handled outside of the cryptographic envelope. This is to minimize any correlatable signals in the metadata, to reduce a verifier's ability to group different presentations based on small header variations from the same issuer. The protected header is always disclosed, whereas payloads can be selectively disclosed. Every issuer protected header MUST have an alg value that identifies a valid JSON Proof Algorithm (JPA). For example: { "alg": "BBS" } 5.1.2. Issuer Payloads Payloads are represented and processed as individual octet strings and arranged in an ordered array when there are multiple payloads. All application context of the placement and encoding of each payload value is out of scope of this specification and SHOULD be well defined and documented by the application or other specifications. JPAs MAY provide software interfaces that perform the encoding of individual payloads which accept native inputs such as numbers, sets, or elliptic curve points. This enables the algorithm to support advanced features such as blinded values and predicate proofs. These interfaces would generate the octet string encoded payload value as well as include protection of that payload in the combined proof value. 5.1.3. Issuer Proof The issuer proof is one or more binary octet strings that are opaque to applications. Individual proof-supporting algorithms are responsible for the contents and security of the proof value, along with any required internal structures. The issuer proof is used by the holder to perform validation, checking that the issuer header and all payloads are properly encoded and protected by the given proof. Miller, et al. Expires 20 March 2025 [Page 12] Internet-Draft json-web-proof September 2024 5.2. Presented Form When an issued JWP is presented, it undergoes a transformation that adds a presentation protected header. It may also have one or more payloads hidden, disclosing only a subset of the original issued payloads. The proof value will always be updated to add integrity protection of the presentation header along with the necessary cryptographic statements to verify the presented JWP. When supported by the underling JPA, a single issued JWP can be used to safely generate multiple presented JWPs without becoming correlatable. A JWP may also be single use, where an issued JWP can only be used once to generate a presented form. In this case, any additional presentations would be inherently correlatable. These are still useful for applications needing only selective disclosure or where new unique issued JWPs can be retrieved easily. 5.2.1. Presentation Protected Header The presented form of a JWP MUST contain a presentation protected header. It is added by the holder and MUST be integrity protected by the underling JPA. This header is used to ensure that a presented JWP cannot be replayed and is cryptographically bound to the verifier it was presented to. While there are not any required values in the presentation header, it MUST contain one or more header values that uniquely identify the presented JWP to both the holder and verifier. For example, header values that would satisfy this requirement include nonce and aud. 5.2.2. Presentation Payloads Any one or more payloads may be non-disclosed in a presented JWP. When a payload is not disclosed, the position of other payloads does not change; the resulting array will simply be sparse and only contain the disclosed payloads. The disclosed payloads will always be in the same array positions to preserve any index-based references by the application between the issued and presented forms of the JWP. How the sparse array is represented is specific to the serialization used. Miller, et al. Expires 20 March 2025 [Page 13] Internet-Draft json-web-proof September 2024 Algorithms MAY support including a proof about a payload in the presentation. Applications then treat that proven payload the same as any other non-disclosed payload and do not include it in the presented array of payloads. Rather, proofs about payloads, such as "age >= 21", are included in the presentation proof. 5.2.3. Presentation Proof The presentation proof is one or more binary octet strings that are opaque to applications. Individual proof-supporting algorithms are responsible for the contents and security of the proof value, along with any required internal structures. The proof of a presented JWP will always be different than the issued proof. At a minimum, it MUST be updated to include protection of the added presentation header. Algorithms SHOULD generate an un-correlatable presentation proof in order to support multiple presentations from a single issued JWP. The algorithm is responsible for representing selective disclosure of payloads in a presented proof. If multiple octet strings are insufficient for representing a proof as defined by an algorithm, the algorithm is responsible for defining how such information is represented within one or more octet strings. 6. Serializations Each disclosed payload MUST be base64url encoded when preparing it to be serialized. The headers and proof are also individually base64url encoded. Like JWS, JWP supports both a Compact Serialization and a JSON Serialization. These serializations both represent the same JSON- based header, payload and proof, and are thus interchangeable without breaking the proof value. 6.1. Compact Serialization The compact serialiation provides a space-efficient encoding of a JWP in URL-safe characters. In addition to the alphabet of unpadded BASE64 URL-safe encoding, it uses the "." and "~" characters as separators. All binary data is BASE64URL encoded, including the octets of the UTF-8 encoded headers and the individual payloads and proof values. Miller, et al. Expires 20 March 2025 [Page 14] Internet-Draft json-web-proof September 2024 Payloads and proofs are each concatenated into a single text form by concatenating the BASE64URL encoded values using the ~ character. Individual payloads are allowed to be omitted; if a payload is omitted, it is represented as a zero-length text value, potentially resulting in leading, trailing, or consecutive ~ characters in the concatenated form. If a payload or proof value was a zero-length octet string, it does not get output as its zero-length BASE64URL-encoded form but as a single _ character. This character does not represent a valid BASE64URL-encoded octet string, allowing it to be distinguished from normally encoded data. The issued form is created by concatenating the base64url-encoded issuer protected header, concatenated payloads, and concatenated proof separated each by a . character. The concatenated payloads MAY be omitted if the application is using detached payloads. The presented form is created by concatenating the base64url-encoded presenter protected header, base64url-encoded issuer protected header, concatenated payloads, and concatenated proof separated each by a . character. The concatenated payloads MAY be omitted if the application is using detached payloads. eyJhbGciOiJCQlMtUFJPT0YiLCJhdWQiOiJodHRwczovL3JlY2lwaWVudC5leGFtcGxlL mNvbSIsIm5vbmNlIjoid3JtQlJrS3RYalEifQ.eyJraWQiOiJIamZjcHlqdVpRLU84WWU yaFFuTmJUOVJiYm5yb2JwdGRuRXhSMERValU4IiwiYWxnIjoiQkJTIn0.MTcxNDUyMTYw MA~MTcxNzE5OTk5OQ~IkRvZSI~IkpheSI~~~.ipVsyiG6U84X0DG8mpfe32Pt7WmW6JEM mWGlm-M8x--rapj0OOIBu2NjrsznGG2GoEZ_da6vjDhcEJy9MGu1udIk8zfQ_-ZgFLmYf fMmXBkrSF4f1JsGlWYf281XBV3ys9pYiPKg_GF_yldcigqQ3O5yX4MhOi7CxeadnQ-Hqq DK_NwchTStzHchzFzzaOoCS7Psaan3fjFXZDePm_2ZVThd63En1h8aLO8hpxg1XChVDmc 0zbL3zlYks1F5po4bSk9a96hsOL2QaPBcdVWOZQ2ENkYeMYf_XUKdGDuEL6OUeSErP5N0 g6g4zc2XXI_3ULw3Pp0l-WgdXZHcw7tXFYlIHheENErCYohMBGpIew8HfYdtwKsoNyz4g dw7GEpp0CfvtzWqfODz8LhriEQbqCY_0jh6YA1tSlQejkMP_vL1QEV7sAIQnlKua1exJe q1LneeNoi3r1fXflNevWfGZqJjmAwe-hX14g7xkcBj50I | Figure: Compact Serialization of Presentation 6.2. JSON Serialization The JSON Serialization is in the form of a JSON object, with property names representing the various components. The issuer key has a string value holding the BASE64URL-encoded issuer protected header. This key MUST be included. Miller, et al. Expires 20 March 2025 [Page 15] Internet-Draft json-web-proof September 2024 The presentation key has a string value holding the BASE64URL-encoded presentation protected header. It MUST be included for presented form, and MUST be omitted for issued form. The payloads key has an array value, representing the ordered sequence of payloads. If a payload has been omitted, it is represented by the JSON value null. A payload is otherwise reprented by the BASE64URL-encoded form of the payload octets. A zero-length payload does not have special encoding rules as needed by compact encoding, and is represented by the zero-length string output by BASE64URL. This key MUST be included unless the application is using detached payloads. The proofs key has an array value, representing the array of octet strings produced by the chosen algorithm. These octets are BASE64URL encoded into a JSON array. This example JSON serialization shows the presentation form with both the issuer and presentation headers, and with the first and third payloads hidden. { "presentation": "eyJhbGciOiJCQlMtUFJPT0YiLCJhdWQiOiJodHRwczovL3JlY2 lwaWVudC5leGFtcGxlLmNvbSIsIm5vbmNlIjoid3JtQlJrS3RYalEifQ", "issuer": "eyJraWQiOiJIamZjcHlqdVpRLU84WWUyaFFuTmJUOVJiYm5yb2JwdGRu RXhSMERValU4IiwiYWxnIjoiQkJTIn0", "payloads": [ "MTcxNDUyMTYwMA", "MTcxNzE5OTk5OQ", "IkRvZSI", "IkpheSI", null, null, null ], "proof": [ "ipVsyiG6U84X0DG8mpfe32Pt7WmW6JEMmWGlm-M8x--rapj0OOIBu2NjrsznGG2G oEZ_da6vjDhcEJy9MGu1udIk8zfQ_-ZgFLmYffMmXBkrSF4f1JsGlWYf281XBV 3ys9pYiPKg_GF_yldcigqQ3O5yX4MhOi7CxeadnQ-HqqDK_NwchTStzHchzFzz aOoCS7Psaan3fjFXZDePm_2ZVThd63En1h8aLO8hpxg1XChVDmc0zbL3zlYks1 F5po4bSk9a96hsOL2QaPBcdVWOZQ2ENkYeMYf_XUKdGDuEL6OUeSErP5N0g6g4 zc2XXI_3ULw3Pp0l-WgdXZHcw7tXFYlIHheENErCYohMBGpIew8HfYdtwKsoNy z4gdw7GEpp0CfvtzWqfODz8LhriEQbqCY_0jh6YA1tSlQejkMP_vL1QEV7sAIQ nlKua1exJeq1LneeNoi3r1fXflNevWfGZqJjmAwe-hX14g7xkcBj50I" ] } | Figure: JSON Serialization of Presentation Miller, et al. Expires 20 March 2025 [Page 16] Internet-Draft json-web-proof September 2024 7. Encrypted JSON Web Proofs Access to JWPs containing non-public material by parties without legitimate access to the non-public information MUST be prevented. This can be accomplished by encrypting the JWP when potentially observable by such parties to prevent the disclosure of private information. The use of an Encrypted JWP, which is a JWE [RFC7516] with a JWP as its plaintext value, is recommended for this purpose. The processing of Encrypted JWPs is identical to the processing of other JWEs. The cty (content type) JWE Header Parameter is used to indicate that the content of the JWE is a JWP. The cty value of the JWE SHOULD be the same as the typ (type) JWP Header Parameter value of the unencrypted JWP to be encrypted. If the JWP has no typ value, then the following JWE Header Parameter cty (content type) values SHOULD be used: * jwp is used to indicate that the content of the JWE is a JWP using the JWP Compact Serialization. * jwp+json is used to indicate that the content of the JWE is the UTF-8 encoding of a JWP using the JWP JSON Serialization. The cty (content type) Header Parameter MUST be present unless the application knows that the encrypted content is a JWP by another means or convention, in which case the cty value MAY be omitted. 8. Detached Payloads In some contexts, it is useful to make statements about payloads which are not themselves contained within the JWP, similar to "Detached Content" in JWS [RFC7515]. For this purpose, the compact, JSON and CBOR serializations allow for all payloads to be omitted from a serialized form. While this is a legal serialization, it is not on its own able to be verified. The recipient is expected to perform some sequence of steps defined by the application to recreate the array of payloads, including order and optionality. This effectively recreates the fully specified serialization of the JWP. 9. Security Considerations Notes to be expanded: * Requirements for supporting algorithms, see JPA * Application interface for verification Miller, et al. Expires 20 March 2025 [Page 17] Internet-Draft json-web-proof September 2024 * Data minimization of the protected header * To prevent accidentally introducing linkability, when an issuer uses the same key with the same grouping of payload types, they SHOULD also use the same issuer protected header. Each of these headers SHOULD have the same base64url-serialized value to avoid any non-deterministic JSON serialization. 10. IANA Considerations The following registration procedure is used for all the registries established by this specification. Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jose-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register JWP header parameter: example"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution. Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear. IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list. It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts. Miller, et al. Expires 20 March 2025 [Page 18] Internet-Draft json-web-proof September 2024 10.1. JSON Web Proof Header Parameters Registry This specification establishes the IANA "JSON Web Proof Header Parameters" registry for Header Parameter names. The registry records the Header Parameter name and a reference to the specification that defines it. The same Header Parameter name can be registered multiple times, provided that the parameter usage is compatible between the specifications. Different registrations of the same Header Parameter name will typically use different Header Parameter Usage Locations values. 10.1.1. Registration Template * Header Parameter Name: The name requested (e.g., "kid"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. * Header Parameter Description: Brief description of the Header Parameter (e.g., "Key ID"). * Header Parameter Usage Location(s): The Header Parameter usage locations, which should be one or more of the values Issued or Presented. Other values may be used with the approval of a Designated Expert. * Change Controller: For Standards Track RFCs, list the "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. * Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 10.1.2. Initial Registry Contents This section registers the Header Parameter names defined in Section 4.1 in this registry. 10.1.2.1. Algorithm Header Parameter * Header Parameter Name: alg * Header Parameter Description: Algorithm * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 4.1.1 of this specification Miller, et al. Expires 20 March 2025 [Page 19] Internet-Draft json-web-proof September 2024 10.1.2.2. Key ID Header Parameter * Header Parameter Name: kid * Header Parameter Description: Key ID * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 4.1.2 of this specification 10.1.2.3. Type Header Parameter * Header Parameter Name: typ * Header Parameter Description: Type * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 4.1.3 of this specification 10.1.2.4. Critical Header Parameter * Header Parameter Name: crit * Header Parameter Description: Critical * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 4.1.4 of this specification 10.1.2.5. Issuer Header Parameter * Header Parameter Name: iss * Header Parameter Description: Issuer * Header Parameter Usage Location(s): Issued, Presented * Change Controller: IETF * Specification Document(s): Section 4.1.7 of this specification 10.1.2.6. Audience Header Parameter * Header Parameter Name: aud * Header Parameter Description: Audience * Header Parameter Usage Location(s): Presented * Change Controller: IETF * Specification Document(s): Section 4.1.8 of this specification 10.1.2.7. Nonce Header Parameter * Header Parameter Name: nonce * Header Parameter Description: Nonce * Header Parameter Usage Location(s): Presented * Change Controller: IETF * Specification Document(s): Section 4.1.9 of this specification Miller, et al. Expires 20 March 2025 [Page 20] Internet-Draft json-web-proof September 2024 10.1.2.8. Claims Header Parameter * Header Parameter Name: claims * Header Parameter Description: claims * Header Parameter Usage Location(s): Issued * Change Controller: IETF * Specification Document(s): Section 4.1.10 of this specification 10.2. Media Type Registration 10.2.1. Registry Contents This section registers the application/jwp media type [RFC2046] in the IANA "Media Types" registry (#IANA.MediaTypes) in the manner described in [RFC6838], which can be used to indicate that the content is a JWP using the JWP Compact Serialization. This section also registers the application/jwp+json media type in the IANA "Media Types" registry, which can be used to indicate that the content is a JWP using the JWP JSON Serialization. 10.2.1.1. The application/jwp Media Type * Type name: application * Subtype name: jwp * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: 8bit; application/jwp values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~') characters * Security considerations: See Section 9 of this specification * Interoperability considerations: n/a * Published specification: this specification * Applications that use this media type: TBD * Fragment identifier considerations: n/a * Additional information: - Magic number(s): n/a - File extension(s): n/a - Macintosh file type code(s): n/a * Person & email address to contact for further information: Michael B. Jones, michael_b_jones@hotmail.com * Intended usage: COMMON * Restrictions on usage: none * Author: Michael B. Jones, michael_b_jones@hotmail.com * Change Controller: IETF * Provisional registration? No 10.2.1.2. The application/jwp+json Media Type Miller, et al. Expires 20 March 2025 [Page 21] Internet-Draft json-web-proof September 2024 * Type name: application * Subtype name: jwp+json * Required parameters: n/a * Optional parameters: n/a * Encoding considerations: 8bit; application/jwp+json values are represented as a JSON Object; UTF-8 encoding SHOULD be employed for the JSON object. * Security considerations: See Section 9 of this specification * Interoperability considerations: n/a * Published specification: this specification * Applications that use this media type: TBD * Fragment identifier considerations: n/a * Additional information: - Magic number(s): n/a - File extension(s): n/a - Macintosh file type code(s): n/a * Person & email address to contact for further information: Michael B. Jones, michael_b_jones@hotmail.com * Intended usage: COMMON * Restrictions on usage: none * Author: Michael B. Jones, michael_b_jones@hotmail.com * Change Controller: IETF * Provisional registration? No 10.3. Structured Syntax Suffix Registration 10.3.1. Registry Contents This section registers the +jwp structured syntax suffix [RFC6838] in the IANA "Structured Syntax Suffix" registry (#IANA.StructuredSuffix) in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as a JWP using the JWP Compact Serialization. 10.3.1.1. The +jwp Structured Syntax Suffix * Name: JSON Web Proof (JWP) * +suffix: +jwp * References: Section 6.1 of this specification * Encoding considerations: binary; JWP values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~') characters * Interoperability considerations: n/a * Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +jwp SHOULD be as specified for "application/jwp". (At publication of this document, there is no fragment identification syntax defined for "application/jwp".) Miller, et al. Expires 20 March 2025 [Page 22] Internet-Draft json-web-proof September 2024 The syntax and semantics for fragment identifiers for a specific "xxx/yyy+jwp" SHOULD be processed as follows: For cases defined in +jwp, where the fragment identifier resolves per the +jwp rules, then process as specified in +jwp. For cases defined in +jwp, where the fragment identifier does not resolve per the +jwp rules, then process as specified in "xxx/ yyy+jwp". For cases not defined in +jwp, then process as specified in "xxx/ yyy+jwp". * Security considerations: See Section 9 of this specification * Contact: Michael B. Jones, michael_b_jones@hotmail.com * Author/Change controller: IETF 11. References 11.1. Normative References [I-D.ietf-jose-json-proof-algorithms] Miller, J., Jones, M. B., and D. Waite, "JSON Proof Algorithms", Work in Progress, Internet-Draft, draft-ietf- jose-json-proof-algorithms-05, 22 July 2024, . [I-D.ietf-jose-json-proof-token] Miller, J., Jones, M. B., and D. Waite, "JSON Proof Token", Work in Progress, Internet-Draft, draft-ietf-jose- json-proof-token-05, 22 July 2024, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . 11.2. Informative References Miller, et al. Expires 20 March 2025 [Page 23] Internet-Draft json-web-proof September 2024 [ECMAScript] Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA 262, June 2011, . [I-D.irtf-cfrg-bbs-signatures] Looker, T., Kalos, V., Whitehead, A., and M. Lodder, "The BBS Signature Scheme", Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs-signatures-06, 26 June 2024, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Miller, et al. Expires 20 March 2025 [Page 24] Internet-Draft json-web-proof September 2024 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [VC-DATA-MODEL-2.0] Sporny, M., Jr, T. T., Herman, I., Jones, M. B., and G. Cohen, "Verifiable Credentials Data Model 2.0", 27 December 2023, . Appendix A. Acknowledgements This work was incubated in the DIF Applied Cryptography Working Group (https://identity.foundation/working-groups/crypto.html). We would like to thank Brent Zundel for his valuable contributions to this specification. Appendix B. Document History [[ To be removed from the final specification ]] -06 * Update reference to new repository home. * Fixed #83: Added encrypted JWPs. * Added additional clarification around the compact and JSON serializations * Added text around fully detached payloads -05 * Clarify the use of multiple octet strings in presentation proofs. * Update BBS algorithm example in JSON serialization to show the proof as an array with a single octet string. * Move single-use example appendix from JWP to JPA. * Registered +jwp structured syntax suffix. -04 * Refactoring figures and examples to be built from a common set across all three documents. -03 * Improvements resulting from a full proofreading. * Populated IANA Considerations section. * Specified JWP Header Parameters. Miller, et al. Expires 20 March 2025 [Page 25] Internet-Draft json-web-proof September 2024 * Specified representation of zero-length disclosed payloads for the compact serialization. * Specified that algorithms may supply multiple octet strings for the proof, which are separated by ~ characters in the compact serialization. * Updated to use BBS draft -05. * Added Terminology Section. -02 * Update reference to current BBS algorithm -01 * Correct cross-references within group. -00 * Created initial working group draft based on draft-jmiller-jose- json-web-proof-01 Authors' Addresses Jeremie Miller Ping Identity Email: jmiller@pingidentity.com David Waite Ping Identity Email: dwaite+jwp@pingidentity.com Michael B. Jones Self-Issued Consulting Email: michael_b_jones@hotmail.com URI: https://self-issued.info/ Miller, et al. Expires 20 March 2025 [Page 26]