I needed to review the document with a fine tooth comb for the shepherd report and came up with the following issues.
1. If you are going to define ASCII and UT8 in section 1.1, you should probably define BASE64URL since you are using them in the same manner. 2. Is it possible to use a UTF-16 string in section 3 for b64=false? This does not seem to be explicitly rule out. It would not be an issue for b64 encoded versions of the payload. 2. Should have a flattened version of the structure in section 4.1 as well for comparison purposes. 3. In section 5.3 I find the sentence about performing escape processing slightly confusing. It is not clear what operations are being applied in which direction. Additionally, there appears to be a requirement that UTF-8 encoding be applied which is not reflected in Section 3. 4. Please remove the double-quote marker for JWS JSON Serialization in section 7. This is not and never has been a problem (as noted by the fact that there is no restriction about double-quotes in this document). The first delimiter is a problem and should be note. Leaving in the whitespace issues is reasonable as it could get messed up, although it should not, for the JSON encoding. 5. You still need to respond to the last pair of emails from myself and James about the 'crit' parameter usage. I think that some text will be require for this. I note that he and I both described the same situation where this makes a difference. This may be a requirement on crit or just a security consideration that needs to be discussed. 6. Curiosity. If an application sends some messages detached an some in a URL safe form, would you consider that to be a case where an application could use b64 based on context for some messages but not others? Jim _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
