I have refreshed the draft which talks about what is being discussed in Section 3 <https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3> paragraph 2 as:
http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-03 It just talks about Sender Constraint now, dropping all the things about Key Confirmation. Cheers, Nat 2015-03-25 22:37 GMT+09:00 Nat Sakimura <sakim...@gmail.com>: > Dear OAuthers: > > Here is my belated review comments on > draft-ietf-oauth-proof-of-possession-02 > > Below, [POPA] stands for > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 > > Abstract > ============ > It is probably better to spell out that this document is describing the > JWT format that can be used for sender constraint (5.2 of [POPA]) and key > confirmation (5.3 of [POPA]). This will make it easier for the reader to > understand what this document aims at. > > Accordingly, we should consider the title change to something like: > JWT Sender Confirmation Token Syntax > OR > borrowing from the financial concept which I believe is the origin of the > concept of "bearer token", > JWT Registered Token Syntax > -- here, "Registered" mean that either the sender constraint or key > confirmation is registered within or in conjunction with the token. > > 1. Introduction > ============== > Consider referencing draft-ietf-oauth-pop-architecture. > It will be clearer for the reader then, and the text will be shorter. > > 2. Terminology - Presenter > ======================== > Sentence 1 > ------------------- > Not sure if the first sentence is accurately reflecting the intent. > It excludes rogue party presenting the token (and fails) from presenter. > If so, it is fine but using more qualified term like "authorized > presenter" may make it easier > for the reader to parse. > > Otherwise revise the definition. > > Sentence 2 > ------------------- > "issuer or a party different from the issuer" is not constraining anything > and meaningless. > There are more easier to parse and accurate text coming in the main text, > too. > Drop. > > 3. Proof-Of-Posession Representation > ============================== > Title > --------- > Perhaps "Sender Representation in JWT" is more reflective of the content. > > Para 2 > ------------- > The paragraph describes two ways of sender confirmation: > (1) Sender Constraint > (2) Key Confirmation > It should refer to 5.2 and 5.3 of [POPA] for it, as well as align the > terminology. > > Then, it goes on to describe (1) very briefly, in which it is just > spelling out "iss" and "sub". > > I understand the use of sub in this section comes down from SAML but I > feel that some separation between sub and presenter would be nice. > > For example, when I am presenting the token using an app that I installed > on my iPhone, the presenter is that app and not me, while the sub still may > be me. The app is the authorized presenter/party (azp) of the token. The > JWT may well be about the sub but presented by some software component that > should be independently identified. > > So my proposal is to create a new subsection on (1) for the completeness, > which is going to be a new 3.1, and to use a claim like "azp" instead of > "sub" to identify the presenter. Less overload would cause less confusion > later, IMHO. > > 3.1 > ====== > Title > -------- > Perhaps "Confirmation Key Representation for an Asymmetric Key" is more > reflective of the content. > > 3.2 > ======== > Title > ----------- > Perhaps "Confirmation Key Representation for a Symmetric Key" is more > reflective of the content. > > Last Para > ----------------- > I feel a bit like needing to sniff into the content of jwk to find out > what type may not be optimal, though I do not have a concrete proposal a > this time. > > 3.3 > ====== > Title > --------- > Perhaps "Confirmation Key Representation by Key ID" is more reflective of > the content. > > Para 1 > ----------- > There has been some discussion of using thumbprint instead of a blob > "kid". > This is a valid option. If we are to overload the "kid" member for this > purpose, we need to find a way to signal that it is a thumbprint. > It may very well be better to define a separate member name then for the > thumbprint. The title then changes to "-- by Key ID" to "-- by reference". > > Also, it is conceivable to use the combination of "kid" and "jku". This > aspect is not spelled out here but appears that some magic happens for the > key distribution. > > 3.4 > ======== > Since "cnf" appears before 3.4, it may be better to bring 3.4 at the > front. > > 5.2.2 > ========= > Add "azp" and "jkt". > > o Confirmation Method Value: "azp" > o Confirmation Method Description: Client ID of the Authorized Presenter > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jkt" > o Confirmation Method Description: JWK Thumbprint of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > > o Confirmation Method Value: "jku" > o Confirmation Method Description: JWK URI of the Confirmation Key > o Change Controller: IESG > o Specification Document(s): Section [TBD] of [[ this document ]] > > Privacy Consideration > ======================== > It is missing privacy consideration. It is not required per se, but since > Key Confirmation method with ephemeral key can be less privacy intrusive > compared to other sender confirmation method so adding some text around it > may be a good idea. > > Best, > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
