[stir] draft-ietf-stir-passport-08

[Jim Schaad <[e-mail]>]

Here is a review of the document as a whole.

* Section 4 - para 3 - The term "key values" is potentially ambiguous.  This
could refer either to the value of the key or the value the key is pointing
to.  I would suggest making this clear.

* Section 4 - para 3 - The form you are using for encoding of claims values
has two problems.  The first is that this does not match what the JSON
document says to use "\uXXXX".  The second is that as written, it is
ambiguous.  If I have the US-ASCII string of "%ABCD" then it does not need
to be percent encoded as the string is not outside of the US-ASCII range.

  * Section 4.2.1 - General - I am having a hard time with this section
because it is not highlighting the last piece of information that I think I
need to understand for this.  From what I read, I think that dest == aud in
terms of JWT - that is the target of the statement.  Orig == iss in terms of
JWT - that is the entity that issued the statement.  I don't see anything
that is telling me what the sub of the JWT is supposed to be. 

It would also be good to say why different items are being defined that
appear to be the same thing as already exist in JWT terms. (Yes, at the core
it is because the types are different.)

* Section 4.2.X - you are not telling me that these are arrays of "some
type" rather than the "some type".

 * Section 4.2.2 - You are stating that things must occur in a specific
order.  This is not "normal" JSON behavior and not all JSON serializers may
be able to support this behavior.  I think you need some justification
someplace.

* Section 5 - I am having a hard time finding the lexicographic order and
white space rules quickly.  A pointer might be reasonable.

* Section 7 - One issue that I think you need to address in the extension
section is that signaling protocols need to identify what these new items
are so that they can be picked up and placed into the PASSporT when it is
reconstructed.  The destination does not have to understand the extension,
but it does need to understand that the extension exists.

* Section 8 - You have a problem in that there are no rules in RFC 7638 for
dealing with serialization of integers.  Given that some of the fields in
the JWT are integers this needs to be addressed.  You might want to move
this justification to the top of the document so that people are prepared
for and look for this.

* Section 8 - Wording problem with saying that "dest" and "mky" need to
follow their OWN rules.  Are these really defined elsewhere or do you just
use the standard rules recursively.

* Section 9.2 - Consider using a list structure for the asterisk leading
list in this section.

* Section 10.1.1 - Encoding Considerations - This could be 7 bit as the
value is base64 encoded for normal values and would be UTF8 if you used the
full JOSE signature structure which you do not.

* General - I was really tired when I read through this and I kept getting
tripped up on prose.  I did not write down all of the items which bothered
me and now I have read it enough that it is harder for me to locate them.
However, I would request that the authors perform some method of detailed
reading to check for this.  I frequently read the text aloud to myself for
this purpose.  Alternatively, you can just wait for the copy editors.

Jim