My vote is for making it optional but verifying it if it is sent.
", "time": "2022-11-07T09:52:09Z"}, {"author": "George Fletcher", "text": "+1 to what Aaron said
", "time": "2022-11-07T09:53:23Z"}, {"author": "Kai Lehmann", "text": "Does it matter how the encoder works? Both sides see the same string in the end
", "time": "2022-11-07T10:50:50Z"}, {"author": "David Waite", "text": "The edge cases are nasty - Unicode normalizations for instance differ by version and by locale (e.g. do you get a \"TW\" flag)
", "time": "2022-11-07T10:51:15Z"}, {"author": "David Waite", "text": "well thats grapheme representation; the locale specific normalizations are very limited
", "time": "2022-11-07T10:51:56Z"}, {"author": "Benjamin Schwartz", "text": "Clearly we just need a hash function over the space of Unicode codepoints
", "time": "2022-11-07T10:57:39Z"}, {"author": "Kai Lehmann", "text": "How about sending it not as JSON encoded string, but as base64 encoded JWT bodies?
", "time": "2022-11-07T11:01:33Z"}, {"author": "George Fletcher", "text": "A test suite of sd-jwts that libraries must be able to handle seems like a good idea especially since the validation and verification can be done offline
", "time": "2022-11-07T11:06:19Z"}, {"author": "Orie Steele", "text": "Since JCS was mentioned, https://datatracker.ietf.org/doc/html/rfc8785
", "time": "2022-11-07T11:08:44Z"}, {"author": "David Waite", "text": "FWIW I don't know if JCS would be appropriate (even ignoring the larger concerns) because it requires a JCS-compatible parser to prevent the text issue mentioned. There's no guarantee that an existing JWT implementation will happen to have a JSON library that meets JCS's additional requirements
", "time": "2022-11-07T11:19:03Z"}, {"author": "Orie Steele", "text": "Agreed, I see the proposal to restrict the set of supported claims as being somewhat similar... Basically what the issuer commits to is what the verifier needs to get... How that happens, with hardening or canonicalization needs to be agreed to... And any agreement that tunnels JSON through strings or restricts JSON to make is safer to process will need to be agreed to.
", "time": "2022-11-07T11:26:18Z"}, {"author": "George Fletcher", "text": "In UMA [https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html] Section 3.2.1 UMA defines a WWW-Authenticate parameter for the as_uri
", "time": "2022-11-07T11:30:29Z"}, {"author": "Pieter Kasselman", "text": "+1 o John's comment on security concerns
", "time": "2022-11-07T11:33:16Z"}, {"author": "Pieter Kasselman", "text": "Another concern is that it may be a very attractive social engineering attack vector
", "time": "2022-11-07T11:34:02Z"}, {"author": "Pieter Kasselman", "text": "Attackers can abuse this to change context and mislead users
", "time": "2022-11-07T11:34:22Z"}, {"author": "David Waite", "text": "the other missing piece added since then is the resource request parameter on the token endpoint. This means that the AS can judge whether the request should be allowed, with asterisks.
", "time": "2022-11-07T11:34:38Z"}, {"author": "George Fletcher", "text": "Didn't we do PoP for cookies with token-binding? =P
", "time": "2022-11-07T11:34:38Z"}]