From 3734ae0d97e2ac8494720af75ed40a514988b29c Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 6 Aug 2024 17:08:48 -0700 Subject: [PATCH 01/15] Remove vestigial use of presentation_header --- draft-ietf-jose-json-proof-algorithms.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-jose-json-proof-algorithms.md b/draft-ietf-jose-json-proof-algorithms.md index e18401fa..ebcb3329 100644 --- a/draft-ietf-jose-json-proof-algorithms.md +++ b/draft-ietf-jose-json-proof-algorithms.md @@ -183,8 +183,6 @@ This specification registers the `nonce` header parameter for the presentation p The presentation protected header MAY contain other header parameters that are either provided by the verifier or by the holder. These presentation header parameters SHOULD NOT contain values that are common across multiple presentations and SHOULD be unique to a single presentation and verifier. -In various examples in this specification, the octet string serialized presentation header is referenced as `presentation_header`. - ### Presentation > Editor's Note: The current definition here is incomplete, the holder's signature needs to also incorporate the presented proof. @@ -803,6 +801,7 @@ The BBS examples were generated using the library at https://github.com/mattrglo [[ To be removed from the final specification ]] * Update reference to new repository home + * Fixed #77: Removed vestigial use of `presentation_header`. -05 From d4457454f8a9a5a55dd404085843d794e82fb04a Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 6 Aug 2024 18:14:47 -0700 Subject: [PATCH 02/15] Correct JPT example location --- draft-ietf-jose-json-proof-token.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-jose-json-proof-token.md b/draft-ietf-jose-json-proof-token.md index 379ba10c..baf7435e 100644 --- a/draft-ietf-jose-json-proof-token.md +++ b/draft-ietf-jose-json-proof-token.md @@ -153,9 +153,9 @@ Always an octet string of valid JSON text. * knowledge * linking -# Example JPT +# Example JPTs -See the [@!I-D.ietf-jose-json-web-proof] appendix. +See the examples in Appendix A.1 of [@I-D.ietf-jose-json-proof-algorithms]. # Security Considerations From 8da217b79dba5df6d00d057dbe9dc67becf1734d Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 6 Aug 2024 18:45:22 -0700 Subject: [PATCH 03/15] Enhance JPT payload description --- draft-ietf-jose-json-proof-token.md | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/draft-ietf-jose-json-proof-token.md b/draft-ietf-jose-json-proof-token.md index 379ba10c..fa9e8c58 100644 --- a/draft-ietf-jose-json-proof-token.md +++ b/draft-ietf-jose-json-proof-token.md @@ -133,20 +133,29 @@ The following is an example JWP Protected Header that includes a `cid`: > Editor's Note: This section is incomplete. Use it only as an indicator of the intended direction. Application resolves each claim as required when processing the JPT. Resolution can result in one of three things: -1. A disclosed JSON value -2. A custom proof method -3. A `null` value +1. A disclosed JSON value. +1. An indicator that the value was not disclosed. +1. An algorithm-specific proof method. ## Disclosed -Always an octet string of valid JSON text. +A disclosed payloads are represented as a base64url-encoded UTF-encoded octet string +representing a valid JSON value. + +## Undisclosed + +The placeholder indicating that a payload was not disclosed is represented as +a `null` value for the JWP JSON Serialization +or the empty string value for the JWP Compact Serialization. ## Proof Methods -* proof methods can be returned instead of a disclosed payload -* these are generated by the algorithm from information in the JWP's proof value -* a proof method may be custom based on the capabilities of the algorithm -* define common proof method types available? +Proof methods can be returned instead of a disclosed payload. +These are generated in an algorithm-specific manner from information in the JWP's proof value. + +A proof method may be custom based on the capabilities of the algorithm. + +* TBD: Describe common proof method types available? * range * membership * time @@ -205,6 +214,7 @@ for his valuable contributions to this specification. [[ To be removed from the final specification ]] * Update reference to new repository home + * Enhance JPT payload description. -05 From 5827a5ce72a3081c83955f8869f0c4d05162e177 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 6 Aug 2024 18:58:51 -0700 Subject: [PATCH 04/15] Discuss issued and presented forms of JPTs --- draft-ietf-jose-json-proof-token.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/draft-ietf-jose-json-proof-token.md b/draft-ietf-jose-json-proof-token.md index fa9e8c58..3b611c1c 100644 --- a/draft-ietf-jose-json-proof-token.md +++ b/draft-ietf-jose-json-proof-token.md @@ -128,18 +128,16 @@ The following is an example JWP Protected Header that includes a `cid`: <{{./fixtures/template/jpt-issuer-protected-header-with-cid.json}} -# Payloads +# Presented Claims and Proofs -> Editor's Note: This section is incomplete. Use it only as an indicator of the intended direction. - -Application resolves each claim as required when processing the JPT. Resolution can result in one of three things: +Each claim in the issued form of the JPT results in one of three things in the presented form of the JPT: 1. A disclosed JSON value. 1. An indicator that the value was not disclosed. 1. An algorithm-specific proof method. ## Disclosed -A disclosed payloads are represented as a base64url-encoded UTF-encoded octet string +A disclosed payload is represented as a base64url-encoded UTF-encoded octet string representing a valid JSON value. ## Undisclosed @@ -214,7 +212,7 @@ for his valuable contributions to this specification. [[ To be removed from the final specification ]] * Update reference to new repository home - * Enhance JPT payload description. + * Fixed #99: Discussed issued and presented forms of JPTs. -05 From ea53c45432d497e0cfa608ab2b10bf0d375ea6a3 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 6 Aug 2024 21:20:45 -0700 Subject: [PATCH 05/15] Add encrypted JWPs --- draft-ietf-jose-json-web-proof.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index c4b60fe6..900859a2 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -451,6 +451,29 @@ This example flattened JSON serialization shows the presentation form with both <{{./fixtures/build/bbs-holder.json.jwp.wrapped}}> Figure: JSON Serialization of Presentation +# 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. + +A `cty` (content type) Header Parameter value of `jwp` is used to indicate +that the content of the JWE is a JWP using the JWP Compact Serialization. +A `cty` (content type) Header Parameter value of `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. +In both cases, 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 would typically be omitted. + # Security Considerations {#SecurityConsiderations} Notes to be expanded: @@ -657,7 +680,8 @@ 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. +which can be used to indicate that the media type is encoded as a JWP +using the JWP Compact Serialization. #### The +jwp Structured Syntax Suffix @@ -767,7 +791,8 @@ for his valuable contributions to this specification. [[ To be removed from the final specification ]] - * Update reference to new repository home + * Update reference to new repository home. + * Fixed #83: Added encrypted JWPs. -05 From 00598dac23e931f7eccac8922fd31740777adc27 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Thu, 8 Aug 2024 18:31:52 -0700 Subject: [PATCH 06/15] Use JWP typ value as JWE cty value --- draft-ietf-jose-json-web-proof.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index 900859a2..03f3b08c 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -465,14 +465,19 @@ is recommended for this purpose. The processing of Encrypted JWPs is identical to the processing of other JWEs. -A `cty` (content type) Header Parameter value of `jwp` is used to indicate -that the content of the JWE is a JWP using the JWP Compact Serialization. -A `cty` (content type) Header Parameter value of `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. -In both cases, the `cty` (content type) Header Parameter MUST be present +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 JWP. +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 would typically be omitted. +in which case the `cty` value MAY be omitted. # Security Considerations {#SecurityConsiderations} From a57873394a7d36545e03db5f067a21fcade239d4 Mon Sep 17 00:00:00 2001 From: "Michael B. Jones" Date: Tue, 20 Aug 2024 15:57:07 -0700 Subject: [PATCH 07/15] Applied DW's suggestion Co-authored-by: David Waite --- draft-ietf-jose-json-proof-token.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-jose-json-proof-token.md b/draft-ietf-jose-json-proof-token.md index 3b611c1c..b8c67d6f 100644 --- a/draft-ietf-jose-json-proof-token.md +++ b/draft-ietf-jose-json-proof-token.md @@ -137,8 +137,7 @@ Each claim in the issued form of the JPT results in one of three things in the p ## Disclosed -A disclosed payload is represented as a base64url-encoded UTF-encoded octet string -representing a valid JSON value. +A disclosed payload is represented as a UTF-encoded octet string representing a valid JSON value. ## Undisclosed From dd57464a7590875b96ecac699d4ef2c662a66005 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 20 Aug 2024 20:28:39 -0700 Subject: [PATCH 08/15] Applied modularity suggestion by DW --- draft-ietf-jose-json-proof-token.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-jose-json-proof-token.md b/draft-ietf-jose-json-proof-token.md index 3b611c1c..c84d4d85 100644 --- a/draft-ietf-jose-json-proof-token.md +++ b/draft-ietf-jose-json-proof-token.md @@ -143,8 +143,7 @@ representing a valid JSON value. ## Undisclosed The placeholder indicating that a payload was not disclosed is represented as -a `null` value for the JWP JSON Serialization -or the empty string value for the JWP Compact Serialization. +described in Section 6 (Serializations) of [@!I-D.ietf-jose-json-web-proof]. ## Proof Methods From 9c53809931340247971b60134614bc03b3e1e2c9 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Tue, 20 Aug 2024 20:44:07 -0700 Subject: [PATCH 09/15] Use languege "the unencrypted JWP to be encrypted" --- draft-ietf-jose-json-web-proof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index 03f3b08c..9ffbecec 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -468,7 +468,7 @@ 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 JWP. +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. From 41cb647396d5f36d34f0a7c83344e365f933ead2 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 00:46:25 -0600 Subject: [PATCH 10/15] Correct `pjwk` to `presentation_jwk` --- draft-ietf-jose-json-proof-algorithms.md | 6 +++--- fixtures/mac-h256-fixtures.mjs | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-jose-json-proof-algorithms.md b/draft-ietf-jose-json-proof-algorithms.md index ebcb3329..8ec05294 100644 --- a/draft-ietf-jose-json-proof-algorithms.md +++ b/draft-ietf-jose-json-proof-algorithms.md @@ -273,7 +273,7 @@ Prior to the issuer creating a new JWP, it must have presentation binding inform The presentation key used by the holder must be transferred to the issuer and verified, likely through a challenge and self-signing mechanism. If the holder requires unlinkability, it must also generate a new key that is verified and bound to each new JWP. -How these holder presentation keys are transferred and verified is out of scope of this specification. Protocols such as OpenID Connect can be used to accomplish this. What is required by this definition is that the holder's presentation key MUST be included in the issuer's protected header using the `pjwk` parameter with a JWK as the value. +How these holder presentation keys are transferred and verified is out of scope of this specification. Protocols such as OpenID Connect can be used to accomplish this. What is required by this definition is that the holder's presentation key MUST be included in the issuer's protected header using the `presentation_jwk` parameter with a JWK as the value. ### Issuer Setup @@ -283,7 +283,7 @@ The Shared Secret is used by both the issuer and holder as the MAC method's key ### Issuer Protected Header {#issuer-protected-header} -The holder's presentation key JWK MUST be included in the issuer protected header using the `pjwk` parameter. The issuer MUST validate that the holder has possession of this key through a trusted mechanism such as verifying the signature of a unique nonce value from the holder. +The holder's presentation key JWK MUST be included in the issuer protected header using the `presentation_jwk` parameter. The issuer MUST validate that the holder has possession of this key through a trusted mechanism such as verifying the signature of a unique nonce value from the holder. ### Combined MAC Representation @@ -317,7 +317,7 @@ See the JWS [Presentation Protected Header](#presentation-protected-header) sect > Editor's Note: The current definition here is incomplete, the holder's signature needs to also incorporate the presented proof. -The first value in the presentation proof is the presentation signature. This is a signature over the presentation protected header, using the key specified by the `pjwk` parameter in the issuer protected header. +The first value in the presentation proof is the presentation signature. This is a signature over the presentation protected header, using the key specified by the `presentation_jwk` parameter in the issuer protected header. The second value is the issuer signature over the Combined MAC Representation provided with the issued form. diff --git a/fixtures/mac-h256-fixtures.mjs b/fixtures/mac-h256-fixtures.mjs index 2a0012ee..91b791cf 100644 --- a/fixtures/mac-h256-fixtures.mjs +++ b/fixtures/mac-h256-fixtures.mjs @@ -35,7 +35,7 @@ const holderPrivateKey = crypto.createPrivateKey({ /// Create Issued JWP // Modify the issuer protected header by adding the Holder's public key -issuerProtectedHeaderJSON.pjwk = holderPublicKeyJSON; +issuerProtectedHeaderJSON.presentation_jwk = holderPublicKeyJSON; // encode/sign the issuer protected header w/ the stable key const finalIssuerProtectedHeader = JSON.stringify(issuerProtectedHeaderJSON); From fb4d7c5fad473a0d44139510e7c2089ef1c42022 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 01:03:25 -0600 Subject: [PATCH 11/15] Add additional text around serializations, and define fully detached payloads --- draft-ietf-jose-json-web-proof.md | 38 ++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index 9ffbecec..c98af037 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -425,28 +425,40 @@ The algorithm is responsible for representing selective disclosure of payloads i 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. +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. ## Compact Serialization {#CompactSerialization} -The individually encoded payloads are concatenated with the `~` character to form an ordered delimited array. Any non-disclosed payloads are left blank, resulting in sequential `~~` characters such that all payload positions are preserved. +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. -A payload which is disclosed but which contains no data (i.e. a zero-length octet string) is encoded as a single `_` character of data, which is not a valid result from base64url-encoding a value. +All binary data is BASE64URL encoded, including the octets of the UTF-8 encoded headers and the individual payloads and proof values. -Additionally, an algorithm MAY supply multiple octet strings for a proof. These are concatenated with the `~` character to form an ordered delimited array. +Payloads and proofs are each concatenated into a single text form by concatenating the BASE64URL encoded values using the `~` character. -The headers, concatenated payloads, and proof value are then concatenated with a `.` character to form the final compact serialization. The issued form will only contain one header and always have three `.` separated parts. The presented form will always have four `.` separated parts, the issued header, followed by the protected header, then the payloads and the proof. +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 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 presenter protected header, 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. <{{./fixtures/build/bbs-holder.compact.jwp.wrapped}}> Figure: Compact Serialization of Presentation ## JSON Serialization {#JSONSerialization} -Non-disclosed payloads in the JSON serialization are represented with a `null` value in the `payloads` array. A zero-length payload is represented as a zero-length base64url encoded sequence, the empty string `""`. +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. + +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. -Proofs are represented as an array of one or more encoded octet strings. +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. -This example flattened JSON serialization shows the presentation form with both the issuer and presentation headers, and with the first and third payloads hidden. +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. <{{./fixtures/build/bbs-holder.json.jwp.wrapped}}> Figure: JSON Serialization of Presentation @@ -479,6 +491,14 @@ 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. +# 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. + # Security Considerations {#SecurityConsiderations} Notes to be expanded: @@ -798,6 +818,8 @@ for his valuable contributions to this specification. * 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 From a50e259397b77884cc8c61250f4ba6caf9004d4e Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 16:42:12 -0600 Subject: [PATCH 12/15] Correct `pjwk` to `presentation_jwk` --- draft-ietf-jose-json-proof-algorithms.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-ietf-jose-json-proof-algorithms.md b/draft-ietf-jose-json-proof-algorithms.md index 8ec05294..09f9c651 100644 --- a/draft-ietf-jose-json-proof-algorithms.md +++ b/draft-ietf-jose-json-proof-algorithms.md @@ -802,6 +802,7 @@ The BBS examples were generated using the library at https://github.com/mattrglo * Update reference to new repository home * Fixed #77: Removed vestigial use of `presentation_header`. + * Correct `pjwk` to `presentation_jwk` -05 From cd290ab53b8b7e12178508f3d58c2ca9e982ee63 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 17:18:09 -0600 Subject: [PATCH 13/15] Update draft-ietf-jose-json-web-proof.md Co-authored-by: Michael B. Jones --- draft-ietf-jose-json-web-proof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index c98af037..169299a1 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -435,7 +435,7 @@ All binary data is BASE64URL encoded, including the octets of the UTF-8 encoded 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. +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. From a17d76c9e9020cfe094ed79dba01a0da9729e389 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 17:18:20 -0600 Subject: [PATCH 14/15] Update draft-ietf-jose-json-web-proof.md Co-authored-by: Michael B. Jones --- draft-ietf-jose-json-web-proof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index 169299a1..81745fa3 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -439,7 +439,7 @@ Individual payloads are allowed to be omitted; if a payload is omitted, it is re 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 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 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 presenter protected header, 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. From 23a9b65fedb7b7fa921a3989b225042e306ca751 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 4 Sep 2024 17:18:33 -0600 Subject: [PATCH 15/15] Update draft-ietf-jose-json-web-proof.md Co-authored-by: Michael B. Jones --- draft-ietf-jose-json-web-proof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-jose-json-web-proof.md b/draft-ietf-jose-json-web-proof.md index 81745fa3..159cbe95 100644 --- a/draft-ietf-jose-json-web-proof.md +++ b/draft-ietf-jose-json-web-proof.md @@ -441,7 +441,7 @@ If a payload or proof value was a zero-length octet string, it does not get outp 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 presenter protected header, 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. <{{./fixtures/build/bbs-holder.compact.jwp.wrapped}}> Figure: Compact Serialization of Presentation