Subject: [jose] Shepherd comments

From: "Jim Schaad" <[email-masked]>
Date: Fri, 23 Oct 2015 22:18:54 -0700

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