Messages 2.1.1 - Need to support crypto agility for hash computations

[Michael Jones]

The at_hash and c_hash computations curently specify use of the SHA-2 algorithms. This should be generalized to support crypto agility - especially since SHA-3 is coming.

[Michael Jones]

Doing this would require additional syntax. If we do this, it should be an optional parameter. We would need a concrete syntax proposal.

[Michael Jones]

Possibly look at the x5c extensibility suggestion in JWS 4.1.5 with the x5t#S256 example. This may or not be the right approach.

[Nat Sakimura]

Hmm. I do not agree with the reason. SHA-3 is likely to be a special purpose algs and we do not foresee replacement to SHA-2 family of hash algorithms. For the bit length, it is already covered by the present text. It can do SHA-256, 384, 512, etc....

[Michael Jones]

Providing this agility may create more complexity than it's worth. John will have a look at the wording. The intent is to reuse the hash associated with the signing algorithm, but this might be hard spec language to write and make understandable, and would likely create interop problems.

[John Bradley]

Implicit & Messages Fixed #637 removed requirement for hash of at_token and code to be SHA2 in Sec 2.1.2.1 and Sec 5.2

Implicit Added Sec 2.5 access token validation </t>

→ <<cset 09d7e4c8cb04>>