From 6b5173df8a7d4d3dcda63280ec9dd8c1295a8334 Mon Sep 17 00:00:00 2001 From: Brian Campbell Date: Wed, 19 Jun 2024 15:32:07 -0600 Subject: [PATCH 1/6] First cut at the DPoP-Inspired Authentication section --- draft-sheffer-wimse-s2s-protocol.md | 109 +++++++++++++++++++++++++++- 1 file changed, 108 insertions(+), 1 deletion(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index d2fd698..771540b 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -269,7 +269,7 @@ Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1 jYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU 1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV 6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp -6eL1M486XmRgl3uyjj6R_iuzNOA + 6eL1M486XmRgl3uyjj6R_iuzNOA ~~~ {: title="An example Workload Identity Token HTTP Header Field"} @@ -279,6 +279,109 @@ etc., are all valid and equivalent header field names. However, case is signific ## Option 1: DPoP-Inspired Authentication {#dpop-esque-auth} +This option, inspired by the OAuth DPoP specification {{?RFC9449}}, uses a DPoP-like mechanism to authenticate +the calling workload in the context of the request. The WIMSE Identity Token {{to-wit}} is sent in the request as +described in {{wit-http-header}}. An additional JWT, the Workload Proof Token (WPT), is signed by the private key +corresponding to the public key in the WIT. The WPT is sent in the `Workload-Proof-Token` header field of the request. +A WPT contains the following: + +* in the JOSE header: + * `alg`: An identifier for an appropriate JWS asymmetric digital signature algorithm corresponding to + the confirmation key in the associated WIT. + * `typ`: the WPT is explicitly typed, as recommended in {{Section 3.11 of RFC8725}}, + using the `application/wimse-proof+jwt` media type. +* in the JWT claims: + * `iss`: The issuer of the token, which is the calling workload, represented by the same value as the `sub` claim + of the associated WIT. + * `aud`: The audience of the token contains the the HTTP target URI ({{Section 7.1 of RFC9110}}) of the request + to which the WPT is attached, without query or fragment parts. + * `iat`: The time at which the token was created (as defined in {{Section 4.1.6 of RFC7519}}). + * `jti`: A unique identifier for the token. + * `ctx_token_hash`: Hash of the OAuth access token, Transaction Token {{?I-D.ietf-oauth-transaction-tokens}}, + or other token in the request that might convey end-user identity and authorization context of the request. + The value MUST be the result of a base64url encoding (as defined in {{Section 2 of RFC7515}}) the SHA-256 hash of + the ASCII encoding of the associated token's value. + +An example WPT might look like the following: + +~~~ jwt +eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZERTQSJ9.eyJpc3MiOiJ3aW1z +ZTovL2V4YW1wbGUuY29tL3NwZWNpZmljLXdvcmtsb2FkIiwiYXVkIjoiaHR0cHM6Ly9zZ +XJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJpYXQiOjE3MTc2MTI1NDUsImp0aSI6Il9fYn +djNEVTQzNhY2MyTFRDMS1feCIsImN0eF90b2tlbl9oYXNoIjoiQ0w0d2pmcFJtTmYtYmR +ZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.YVS0gGOnsCK5xWhE9lcRzp0CDpl +TGLDv3lUK4dSF_o2uw2wh6I2FOwsa0OmUMeTAr-qO0bJJBjSOy64UKBekCg + +~~~ +{: #example-wpt title="Example Workload Proof Token (WPT)"} + +The decoded JOSE header of the WPT from the example above is shown here: + +~~~ json +{ + "typ": "wimse-proof+jwt", + "alg": "EdDSA" +} +~~~ +{: title="Example WPT JOSE Header"} + +The decoded JWT claims of the WPT from the example above are shown here: + +~~~ json +{ + "iss": "wimse://example.com/specific-workload", + "aud": "https://service.example.com/path", + "iat": 1717612545, + "jti": "__bwc4ESC3acc2LTC1-_x", + "ctx_token_hash": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI" +} +~~~ +{: title="Example WPT Claims"} + +An example of an HTTP request with both the WIT and WPT from prior examples is shown below: + +~~~ http-message +POST /path HTTP/1.1 +Host: service.example.com +Content-Type: application/json +Authorization: Bearer 16_mAd0GiwaZokU26_0902100 +Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1 + NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN + 0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXN + lOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmN + jYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU + 1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV + 6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp + 6eL1M486XmRgl3uyjj6R_iuzNOA +Workload-Proof-Token: eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZER + TQSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3NwZWNpZmljLXdvcmtsb2FkIi + wiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJpYXQiOjE3MT + c2MTI1NDUsImp0aSI6Il9fYndjNEVTQzNhY2MyTFRDMS1feCIsImN0eF90b2tlbl9oYX + NoIjoiQ0w0d2pmcFJtTmYtYmRZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.Y + VS0gGOnsCK5xWhE9lcRzp0CDplTGLDv3lUK4dSF_o2uw2wh6I2FOwsa0OmUMeTAr-qO0 + bJJBjSOy64UKBekCg + +{"do stuff":"please"} +~~~ +{: title="Example HTTP Request with WIT and WPT"} + +To validate the WPT in the request, the recipient MUST ensure the following: + +* There is not more than one `Workload-Proof-Token` header field in the request. +* The `Workload-Proof-Token` header field value is a single and well-formed JWT. +* The WPT signature is valid using the public key from the confirmation claim of the WIT. +* The `typ` JOSE header parameter of the WPT conveys a media type of `wimse-proof+jwt`. +* The `iss` claim of the WPT matches the `sub` claim of the WIT. (note: not sure `iss` in the WPT is necessary) +* The `aud` claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request + in which the WPT was received, ignoring any query and fragment parts. +* The `iat` claim of the WPT is within an acceptable window, e.g. within a few seconds or minutes of the current time. +* Optionally, check that the value of the `jti` claim has not been used before in the time window in which the + respective WPT would be considered valid. +* If presented in conjunction with a token conveying end-user identity or authorization context, the value of + the `ctx_token_hash` claim matches the hash of that token's value. + + + ## Option 2: Authentication Based on HTTP Message Signatures {#http-sig-auth} This option uses the WIMSE Identity Token (ref TBD) to sign the request and optionally, the response. @@ -385,10 +488,14 @@ TODO: maybe a URI Scheme registration of `wimse` in [URI schemes](https://www.ia TODO: `application/wimse-id+jwt` or appropriately bikeshedded media type name (despite my ongoing unease with using media types for typing JWTs) in [Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml). +TODO: `application/wimse-proof+jwt` ... + ## Hypertext Transfer Protocol (HTTP) Field Name Registration TODO: `Workload-Identity-Token` from {{wit-http-header}} +TODO: `Workload-Proof-Token` from {{dpop-esque-auth}} + --- back # Acknowledgments From 7e0ccf79c135477620a6d67fb1b116b74bddff03 Mon Sep 17 00:00:00 2001 From: Brian Campbell <71398439+bc-pi@users.noreply.github.com> Date: Wed, 26 Jun 2024 09:34:22 -0600 Subject: [PATCH 2/6] use exactly rather than not more than per yaron suggestion Co-authored-by: Yaron Sheffer --- draft-sheffer-wimse-s2s-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index 771540b..c9d0401 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -367,7 +367,7 @@ Workload-Proof-Token: eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZER To validate the WPT in the request, the recipient MUST ensure the following: -* There is not more than one `Workload-Proof-Token` header field in the request. +* There is exactly one `Workload-Proof-Token` header field in the request. * The `Workload-Proof-Token` header field value is a single and well-formed JWT. * The WPT signature is valid using the public key from the confirmation claim of the WIT. * The `typ` JOSE header parameter of the WPT conveys a media type of `wimse-proof+jwt`. From 26dff3d954a018216c69f66dce18274ee7f56c1d Mon Sep 17 00:00:00 2001 From: Brian Campbell Date: Wed, 26 Jun 2024 10:12:43 -0600 Subject: [PATCH 3/6] Change WPTs to use exp rather than iat --- draft-sheffer-wimse-s2s-protocol.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index c9d0401..6d77bdd 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -295,7 +295,8 @@ A WPT contains the following: of the associated WIT. * `aud`: The audience of the token contains the the HTTP target URI ({{Section 7.1 of RFC9110}}) of the request to which the WPT is attached, without query or fragment parts. - * `iat`: The time at which the token was created (as defined in {{Section 4.1.6 of RFC7519}}). + * `exp`: The expiration time of the WIT (as defined in {{Section 4.1.4 of RFC7519}}). WPT lifetimes MUST be short, + e.g., on the order of minutes or seconds. * `jti`: A unique identifier for the token. * `ctx_token_hash`: Hash of the OAuth access token, Transaction Token {{?I-D.ietf-oauth-transaction-tokens}}, or other token in the request that might convey end-user identity and authorization context of the request. @@ -307,11 +308,10 @@ An example WPT might look like the following: ~~~ jwt eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZERTQSJ9.eyJpc3MiOiJ3aW1z ZTovL2V4YW1wbGUuY29tL3NwZWNpZmljLXdvcmtsb2FkIiwiYXVkIjoiaHR0cHM6Ly9zZ -XJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJpYXQiOjE3MTc2MTI1NDUsImp0aSI6Il9fYn +XJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3MTc2MTI4MjAsImp0aSI6Il9fYn djNEVTQzNhY2MyTFRDMS1feCIsImN0eF90b2tlbl9oYXNoIjoiQ0w0d2pmcFJtTmYtYmR -ZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.YVS0gGOnsCK5xWhE9lcRzp0CDpl -TGLDv3lUK4dSF_o2uw2wh6I2FOwsa0OmUMeTAr-qO0bJJBjSOy64UKBekCg - +ZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.6BFrZdobweg5cg1NHvSKqEtmqka +3zu78d2E91VKMoO0tP3J0Pwja7GoAOKuU2ztPAH3yfogFyOBS2GKqo4RSDA ~~~ {: #example-wpt title="Example Workload Proof Token (WPT)"} @@ -331,7 +331,7 @@ The decoded JWT claims of the WPT from the example above are shown here: { "iss": "wimse://example.com/specific-workload", "aud": "https://service.example.com/path", - "iat": 1717612545, + "exp": 1717612820, "jti": "__bwc4ESC3acc2LTC1-_x", "ctx_token_hash": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI" } @@ -374,7 +374,8 @@ To validate the WPT in the request, the recipient MUST ensure the following: * The `iss` claim of the WPT matches the `sub` claim of the WIT. (note: not sure `iss` in the WPT is necessary) * The `aud` claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request in which the WPT was received, ignoring any query and fragment parts. -* The `iat` claim of the WPT is within an acceptable window, e.g. within a few seconds or minutes of the current time. +* The `exp` claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably + far in the future SHOULD be rejected. * Optionally, check that the value of the `jti` claim has not been used before in the time window in which the respective WPT would be considered valid. * If presented in conjunction with a token conveying end-user identity or authorization context, the value of From 06948498e55d9cdf8eccc34fc00c2c7c135f2cc0 Mon Sep 17 00:00:00 2001 From: Brian Campbell <71398439+bc-pi@users.noreply.github.com> Date: Wed, 26 Jun 2024 10:46:24 -0600 Subject: [PATCH 4/6] remove the redundant "the" from the sentence --- draft-sheffer-wimse-s2s-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index 6d77bdd..dc287b6 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -293,7 +293,7 @@ A WPT contains the following: * in the JWT claims: * `iss`: The issuer of the token, which is the calling workload, represented by the same value as the `sub` claim of the associated WIT. - * `aud`: The audience of the token contains the the HTTP target URI ({{Section 7.1 of RFC9110}}) of the request + * `aud`: The audience of the token contains the HTTP target URI ({{Section 7.1 of RFC9110}}) of the request to which the WPT is attached, without query or fragment parts. * `exp`: The expiration time of the WIT (as defined in {{Section 4.1.4 of RFC7519}}). WPT lifetimes MUST be short, e.g., on the order of minutes or seconds. From c5b46a1d06829b5ec435f143d16d57a478003706 Mon Sep 17 00:00:00 2001 From: Brian Campbell Date: Wed, 26 Jun 2024 13:51:53 -0600 Subject: [PATCH 5/6] Split ctx_token_hash in to ath, tth, & oth (which is still awkward but a little more explicit and maybe a little better) --- draft-sheffer-wimse-s2s-protocol.md | 38 ++++++++++++++++++----------- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index dc287b6..e83f19e 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -298,10 +298,17 @@ A WPT contains the following: * `exp`: The expiration time of the WIT (as defined in {{Section 4.1.4 of RFC7519}}). WPT lifetimes MUST be short, e.g., on the order of minutes or seconds. * `jti`: A unique identifier for the token. - * `ctx_token_hash`: Hash of the OAuth access token, Transaction Token {{?I-D.ietf-oauth-transaction-tokens}}, - or other token in the request that might convey end-user identity and authorization context of the request. - The value MUST be the result of a base64url encoding (as defined in {{Section 2 of RFC7515}}) the SHA-256 hash of + * `ath`: Hash of the OAuth access token, if present in the request, which might convey end-user identity and + authorization context of the request. The value, as per {{Section 4.1 of RFC9449}}, + is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value. + * `tth`: Hash of the Txn-Token {{?I-D.ietf-oauth-transaction-tokens}}, if present in the request, + which might convey end-user identity and authorization context of the request. The value MUST be the result of + a base64url encoding (as defined in {{Section 2 of RFC7515}}) the SHA-256 hash of the ASCII encoding of the associated token's value. + * `oth`: Hash of any other token in the request that might convey end-user identity and authorization context of the + request. The value MUST be the result of a base64url encoding (as defined in {{Section 2 of RFC7515}}) the + SHA-256 hash of the ASCII encoding of the associated token's value. + (note: this is less than ideal but seems we need something like this for extensibility) An example WPT might look like the following: @@ -309,9 +316,9 @@ An example WPT might look like the following: eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZERTQSJ9.eyJpc3MiOiJ3aW1z ZTovL2V4YW1wbGUuY29tL3NwZWNpZmljLXdvcmtsb2FkIiwiYXVkIjoiaHR0cHM6Ly9zZ XJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3MTc2MTI4MjAsImp0aSI6Il9fYn -djNEVTQzNhY2MyTFRDMS1feCIsImN0eF90b2tlbl9oYXNoIjoiQ0w0d2pmcFJtTmYtYmR -ZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.6BFrZdobweg5cg1NHvSKqEtmqka -3zu78d2E91VKMoO0tP3J0Pwja7GoAOKuU2ztPAH3yfogFyOBS2GKqo4RSDA +djNEVTQzNhY2MyTFRDMS1feCIsImF0aCI6IkNMNHdqZnBSbU5mLWJkWUliWUxuVjlkNXJ +NQVJHd0tZRTEwd1V3ekMwakkifQ.Zq50mcIVTUykQhOBS7lyF93py3q5QOSPIbnI_oESv +j6zSTWi-p0QNNHpKeB4IAgmC8Mt3dBM_rufwCxiKHSmDA ~~~ {: #example-wpt title="Example Workload Proof Token (WPT)"} @@ -333,7 +340,7 @@ The decoded JWT claims of the WPT from the example above are shown here: "aud": "https://service.example.com/path", "exp": 1717612820, "jti": "__bwc4ESC3acc2LTC1-_x", - "ctx_token_hash": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI" + "ath": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI" } ~~~ {: title="Example WPT Claims"} @@ -355,11 +362,11 @@ Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1 6eL1M486XmRgl3uyjj6R_iuzNOA Workload-Proof-Token: eyJ0eXAiOiJ3aW1zZS1wcm9vZitqd3QiLCJhbGciOiJFZER TQSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3NwZWNpZmljLXdvcmtsb2FkIi - wiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJpYXQiOjE3MT - c2MTI1NDUsImp0aSI6Il9fYndjNEVTQzNhY2MyTFRDMS1feCIsImN0eF90b2tlbl9oYX - NoIjoiQ0w0d2pmcFJtTmYtYmRZSWJZTG5WOWQ1ck1BUkd3S1lFMTB3VXd6QzBqSSJ9.Y - VS0gGOnsCK5xWhE9lcRzp0CDplTGLDv3lUK4dSF_o2uw2wh6I2FOwsa0OmUMeTAr-qO0 - bJJBjSOy64UKBekCg + wiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3MT + c2MTI4MjAsImp0aSI6Il9fYndjNEVTQzNhY2MyTFRDMS1feCIsImF0aCI6IkNMNHdqZn + BSbU5mLWJkWUliWUxuVjlkNXJNQVJHd0tZRTEwd1V3ekMwakkifQ.Zq50mcIVTUykQhO + BS7lyF93py3q5QOSPIbnI_oESvj6zSTWi-p0QNNHpKeB4IAgmC8Mt3dBM_rufwCxiKHS + mDA {"do stuff":"please"} ~~~ @@ -371,15 +378,17 @@ To validate the WPT in the request, the recipient MUST ensure the following: * The `Workload-Proof-Token` header field value is a single and well-formed JWT. * The WPT signature is valid using the public key from the confirmation claim of the WIT. * The `typ` JOSE header parameter of the WPT conveys a media type of `wimse-proof+jwt`. -* The `iss` claim of the WPT matches the `sub` claim of the WIT. (note: not sure `iss` in the WPT is necessary) +* The `iss` claim of the WPT matches the `sub` claim of the WIT. (note: not sure `iss` in the WPT is useful or necessary) * The `aud` claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request in which the WPT was received, ignoring any query and fragment parts. * The `exp` claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably far in the future SHOULD be rejected. * Optionally, check that the value of the `jti` claim has not been used before in the time window in which the respective WPT would be considered valid. +* If presented in conjunction with an OAauth access token, the value of the `ath` claim matches the hash of that token's value. +* If presented in conjunction with a Txn-Token, the value of the `tth` claim matches the hash of that token's value. * If presented in conjunction with a token conveying end-user identity or authorization context, the value of - the `ctx_token_hash` claim matches the hash of that token's value. + the `oth` claim matches the hash of that token's value. @@ -484,6 +493,7 @@ TODO IANA TODO: maybe a URI Scheme registration of `wimse` in [URI schemes](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) per {{?RFC7595}} but it's only being used in an example right now and might not even be appropriate. Or maybe use an ietf URI scheme a la [URN Namespace for IETF Use](https://www.iana.org/assignments/params/params.xhtml) somehow. Or maybe nothing. Or maybe something else. +TODO: `tth` and maybe `oth` claim in [JSON Web Token Claims Registry](https://www.iana.org/assignments/jwt/jwt.xhtml) ## Media Type Registration From 2f04e8e5a580c116602f1f7d0f8185b40bfc88a6 Mon Sep 17 00:00:00 2001 From: Yaron Sheffer Date: Thu, 27 Jun 2024 00:03:28 +0300 Subject: [PATCH 6/6] Apply suggestions from code review --- draft-sheffer-wimse-s2s-protocol.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-sheffer-wimse-s2s-protocol.md b/draft-sheffer-wimse-s2s-protocol.md index e83f19e..2672099 100644 --- a/draft-sheffer-wimse-s2s-protocol.md +++ b/draft-sheffer-wimse-s2s-protocol.md @@ -303,10 +303,10 @@ A WPT contains the following: is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value. * `tth`: Hash of the Txn-Token {{?I-D.ietf-oauth-transaction-tokens}}, if present in the request, which might convey end-user identity and authorization context of the request. The value MUST be the result of - a base64url encoding (as defined in {{Section 2 of RFC7515}}) the SHA-256 hash of + a base64url encoding (as defined in {{Section 2 of RFC7515}}) of the SHA-256 hash of the ASCII encoding of the associated token's value. * `oth`: Hash of any other token in the request that might convey end-user identity and authorization context of the - request. The value MUST be the result of a base64url encoding (as defined in {{Section 2 of RFC7515}}) the + request. The value MUST be the result of a base64url encoding (as defined in {{Section 2 of RFC7515}}) of the SHA-256 hash of the ASCII encoding of the associated token's value. (note: this is less than ideal but seems we need something like this for extensibility)