First cut at the DPoP-Inspired Authentication section #19
Conversation
| 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. | ||
|
|
There was a problem hiding this comment.
Can there be more than one context token hash? would this need to be specified as an array or can you have multiple of the same claim in the jwt?
There was a problem hiding this comment.
Can there be more than one context token hash?
This is a good question that I asked myself while writing the above. But didn't have a great sense for so opted for the simple answer of just one.
The whole construct is admittedly somewhat awkward - trying to account/allow for different kinds of tokens that might show up in different places.
would this need to be specified as an array or can you have multiple of the same claim in the jwt?
Multiple of the same claim in the jwt is not allowed (see https://datatracker.ietf.org/doc/html/rfc7519#section-4) so an array is how that kind of data is expressed.
There was a problem hiding this comment.
But maybe a few different claims that conditionally show up would be a better approach. Like ath access token hash - a la https://www.rfc-editor.org/rfc/rfc9449.html#section-4.2-6.2 - and then txth transaction token hash and maybe an oth for other token hash...
There was a problem hiding this comment.
Currently rethinking the construct
There was a problem hiding this comment.
Although we can definitely punt on it for now, I think we could choose a construct that's both simple and extensible.
"signed_headers": {
"txn-token": "txn token hash",
"x-custom-context": "x-custom-context hash"
}Unfortunately we need the WPT to sign miscellaneous stuff, because we don't want a new WIT for every call. Having said that, as far as I can tell it does NOT need to sign the WIT itself.
| * `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. |
There was a problem hiding this comment.
Why isn't aud the WIMSE identity of the target? Wouldn't that be more consistent?
There was a problem hiding this comment.
That, to me, begs a larger philosophical and scoping question about naming and addressing and identity, which is beyond my competence. And in that lacking of competence, I've used an existing, well-known, and widely used means of identifying the target of an HTTP request.
There was a problem hiding this comment.
Hmmph, let's discuss offline. In the meantime, please remove the redundant "the" from the sentence.
There was a problem hiding this comment.
done 0694849 and looking forward to a lively discussion
| 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. | ||
|
|
There was a problem hiding this comment.
Although we can definitely punt on it for now, I think we could choose a construct that's both simple and extensible.
"signed_headers": {
"txn-token": "txn token hash",
"x-custom-context": "x-custom-context hash"
}Unfortunately we need the WPT to sign miscellaneous stuff, because we don't want a new WIT for every call. Having said that, as far as I can tell it does NOT need to sign the WIT itself.
Co-authored-by: Yaron Sheffer <[email protected]>
…t a little more explicit and maybe a little better)
this is the "DPoP-inspired" part
A preview editors' copy of this PR can be seen at http://www.sheffer.org/wimse-s2s/bc-dpop-esque-pop/draft-sheffer-wimse-s2s-protocol.html