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

[Chris Wendt <[e-mail]>]

HI Jim, 

Thanks for the comprehensive review.  I am working through some of the fixes based on your comments.
Meanwhile i have the following responses inline.

-Chris


> On Oct 8, 2016, at 2:15 PM, Jim Schaad <[e-mail]> wrote:
> 
> 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.

I will use the term  “claim value” which is a RFC 7519 term.  One additional question is whether we say same thing for “claim name” as well?  I suppose we allow it.

> 
> * 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.

Could you provide a pointer to the use of “\uXXX" specifically, we had a working group discussion on this text, but if there is something existing, i haven’t been able to find it.

> 
>  * 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.)

I don’t believe the mapping of aud and iss are appropriate here.  The “orig” and “dest” claim is specifically the asserted identity, telephone number of caller and callee, but may not correspond to the issuer/signer of the JWT, e.g. service provider. 

I can explain this in the text if that is helpful.

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

sorry, i’m having trouble figuring out what you mean by this

> 
> * 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.

I plan to move this to the compact form section, since ordering is only really needed for compact form now.

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

same answer as above.

> 
> * 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.

This will be defined in the “using protocol” specification, however i can make that clearer

> 
> * 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.

wondering if the best way to solve this is to note it and make sure that for any passport extensions that use compact form, they specify the handling integers.

> 
> * 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.

will try to clarify

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

Yep, this was just a missed formatting problem

> 
> * 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.

Ok, will look at changing this.

> 
> * 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
> 
> 
>