remove restrictions to not allow MAC-based algorithms #141
Conversation
| 1. The JWT MAY contain other claims. All claims that are not understood by implementations MUST be ignored. | ||
|
|
||
| 2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm. The authorization server MUST reject JWTs with an invalid signature. | ||
| 2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject JWTs with an invalid signature. |
There was a problem hiding this comment.
That would still not allow MAC I believe?
Something like this is used in JWT RFC:
[...] be digitally signed or integrity protected with a Message Authentication Code (MAC) [...]
There was a problem hiding this comment.
The question is if we want to allow public key derived MACs or MACs in general? The former relies on asymmetric mechanism and would be included imo
There was a problem hiding this comment.
I haven't thought too much about this yet, but my gut feeling would be to allow MAC - people need to understand their deployments and requirements, but I could see something like this used in a context where attestation server and AS are operated by the same entity.
I would agree for the PoP (to not allow MACs)
There was a problem hiding this comment.
I agree with @c2bo there are lots of Oauth deployments that use MAC to say secure the AT and I think the Client attestation could be treated somewhat similar in certain deployments but asymmetric is required for the PoP.
Co-authored-by: Christian Bormann <[email protected]>
Closes #130