Richard,
Here is my review
1. I think you should include the abbreviations for CMS and JSON following
the full strings in the abstract
2. Introduction- Para #1 - You should not assume that people are going to
recognize RFC numbers, esp. as they change over time. Please insert the
names of the protocols as well as the references for 4301 and 5246.
3. Introduction - Para #2 - Please insert a protocol name along with RFC3207
- i.e. STARTTLS
4. The X.609 reference should be updated to the 2002 version It is the
most current version
5. Introduction - Para #3 - please move the XML reference next to the XML
text. It currently appears that the XML reference applies to JSON
6. Section #2 - s/JSON Web Algorithms (JWS)/JSON Web Algorithms (JWA)/
7. Section 3 - bullet #3 - s/receiver share only a/receiver share a/
8. Section 3 - The following sentence appears to be missing some words or
punctuation
vvvvvv
However, in order to avoid confusing endpoints that lack the
necessary context need to be able to recognize this and fail cleanly.
9. Section 5.2 - I have two comments in this section
a) I don't understand the need for integrity protection from
modifications from the resource owner - it is what is granting the
permissions to start with
b) You might want to note that using TLS does not protect
confidentiality from the resource owner and client.
10. Section 5.4 - Is Alice sending the message to (Bob) or (B)?
11. Section 5.5 - There was also a discussion in the case of ALTO if the
content should be encoded separately from the integrity (detached content).
Thus the JSON would be carried in the HTTPS header and the body would be the
HTTPS content.
12. Section 5.6 - What is a channel-based digital signature mechanism?
13. Section 5.6 - The document does not say if nested signatures are
sufficient to satisfy the requirement - or if parallel signatures are
required.
Jim
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
