Inline: 2015-08-11 14:12 GMT+09:00 Mike Jones <michael.jo...@microsoft.com>:
> Replies inline… > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura > *Sent:* Wednesday, March 25, 2015 6:38 AM > *To:* oauth > *Subject:* [OAUTH-WG] Review Comments for > draft-ietf-oauth-proof-of-possession-02 > > > > 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. > > > > It does not seem to me that the “Sender Constraint” concept described in > 5.3 of [POPA] is the same > 5.2 I guess, not 5.3. > thing as identifying a proof-of-possession key within a JWT, which is the > purpose of this specification. In this specification, the issuer makes a > statement that the presenter can confirm possession of a key. I don’t know > how that would map into a “Sender Constraint”. For one thing, which party > are you considering to be the “Sender”? Accordingly, I left the abstract > unchanged. > OK. Since the draft was titled "Proof of Possession Semantics for for JSON Web Tokens (JWTs)", I pointed it out that it should not only talk about 5.3 of [POPA] but also 5.2. However, now that you have changed the tile to "Proof of Possession *KEY* Semantics for for JSON Web Tokens (JWTs)", this issue is resolved. It would be nice to state that it is talking about 5.3 of [POPA] in the introduction though. > > > 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. > > > > I changed the title in -03 to “Proof-of-Possession Key Semantics for JSON > Web Tokens (JWTs)” to make it clear this draft is about PoP key semantics > for JWTs – not the proof-of-possession mechanism itself. I’ve already > responded to the “Sender Constraint” suggestion above. Per my earlier > response, I don’t believe that “Registered Token” is standard terminology, > and so would confuse more than it would clarify. > Now that you have clarified that this document is only about 5.3 of [POPA], the title in -03 is appropriate. NOTE: "Registered *" is a very well established term in financial industry, describing kind of "token" needed to be presented to exercise the right assigned to it. e.g., Registered Security, Registered Share Certificate, etc. > > 1. Introduction > > ============== > > Consider referencing draft-ietf-oauth-pop-architecture. > > It will be clearer for the reader then, and the text will be shorter. > > > > Again, I suspect you’re asking me to reference this draft for the “Sender > Constraint” terminology, which is both vaguely defined in [POPA], and > doesn’t match what this specification does. Therefore, I did not do this > here, although other appropriate references to [POPA] are included. > It would be nice to point out that this document is talking about the model presented in 5.3 of [POPA]. My suggestion: Insert ", *as described in section 5.3 of [POPA]"* before the end of the Para 1. This specification defines how to express a declaration in a JSON Web Token (JWT) [JWT] that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key, *as described in section 5.3 of [POPA]. * > > 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. > > > > I believe the “Presenter” definition accurately matches its usage in this > specification. While this is related to a different discussion, I’m not > aware of a definition for “Authorized Presenter” that could be referenced > that would add further clarity beyond the existing definition. (Note that > the OpenID Connect “azp” claim is for an “Authorized Party” to which the > token was issued – not an “Authorized Presenter”. Also, note that the > usage of “azp” in > http://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04 is > inconsistent with its definition in OpenID Connect, and so should probably > be revised to use the “Authorized Party” terminology or removed, as it does > not identify an “Authorized Presenter” in the way that I think you are > using the term.) > > > It is not a good practice to define such a generic word like "presenter". Since you have used "presenter" as party that holds the key, we have lost the word for the rogue party that presents the token without the key. Also, the current definition includes the issuer in the presenter. Issuer is not typically a party that is supposed to present the token to the resource, so the term seems to be especially weird. > 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. > > > > The phrase expresses the intentional **lack of constraint**, by stating > that the presenter might be the issuer or might be a party different from > the issuer. Too many times in the past people thought the two were the > same party (and indeed, this error occurred in several places in -02), > therefore, I believe that expressing this non-constraint adds value. If > you want to suggest alternative wording to express this non-constraint, I’d > be glad to consider it. > What is the most usual case? Is presenter usually the issuer? I do not think so. So, if we really want to express the lack of constraint, then something like this would be better: The presenter is usually distinct from the issuer, but the issuer can be a presenter as well. Also, I have to point out that the characteristics of this sentence is more like a note to definition and not the definition itself. > > > 3. Proof-Of-Posession Representation > > ============================== > > Title > > --------- > > Perhaps "Sender Representation in JWT" is more reflective of the content. > > > > This was changed to “Representations for Proof-of-Possession Keys” in -03 > to clarifying that it is the PoP key being represented, not the > proof-of-possession itself. > OK. > > > 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. > > > > As described above, the “Sender Constraint” terminology in [POPA] does not > match what this specification does. > The title change clarified the situation so now it is ok. > > 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. > > > > Per your request, > https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03#section-3 > was revised to include a description of the use of the “azp” claim as a > choice that applications can employ to identify the presenter, if > appropriate. > Thank you. > > > 3.1 > > ====== > > Title > > -------- > > Perhaps "Confirmation Key Representation for an Asymmetric Key" is more > reflective of the content. > > > > This was changed to “Representation for an Asymmetric Proof-of-Possession > Key”. > Thanks. > > > 3.2 > > ======== > > Title > > ----------- > > Perhaps "Confirmation Key Representation for a Symmetric Key" is more > reflective of the content. > > > > This was changed to “Representation for an Encrypted Symmetric > Proof-of-Possession Key”. > Thanks. > > > 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. > > > > The “jwe” member was introduced in -03 to eliminate the need for this > sniffing. > Thanks. > > > 3.3 > > ====== > > Title > > --------- > > Perhaps "Confirmation Key Representation by Key ID" is more reflective of > the content. > > > > This was changed to “Representation of a Key ID for a Proof-of-Possession > Key”. > Thanks. > > > 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". > > > > For the same reasons that the “jkt” definition was removed from > draft-ietf-jose-jwk-thumbprint, it’s not clear that it’s needed here. > Applications are free to define that the “kid” is to contain a key > thumbprint using a particular hash function. > OK. So you mean that it should be specified in the application layer. That is acceptable, but then mentioning it in the text would be nice. > > > 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. > > > > You’re right that if “kid” is used, unless the key is also transmitted in > the “cnf” claim, distribution of the key is out of scope of the > specification. I can imagine methods using “jku” but it seems like we > should discuss this more before normatively specifying it at this time. > Looking forward to. > > > 3.4 > > ======== > > Since "cnf" appears before 3.4, it may be better to bring 3.4 at the > front. > > > > Agreed. Sorry I missed doing this in -03. I’ll plan to do this in -04. > Looking forward to. Note that this is not an endorsement for structured cnf, but rather, it was just an editorial point that I raised. > > > 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 ]] > > Having a Client ID doesn’t identify a proof-of-possession key, so this > request seems to be out of place relative to the purpose of this > specification. > Indeed. If the title was like before the change, it would have been, but now the title and the scope is smaller, it is out of scope, I think.. > > > 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 ]] > > As discussed earlier, “kid” can already be used to hold a key thumbprint > value. > OK. > > > 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 ]] > > > > We should have a discussion focused specifically on this proposed > addition. I can see the value of it, but would like to get input from more > working group members. What do people think? (If this discussion doesn’t > happen based on this response, we should probably start a separate thread > on this topic.) > OK. > > > 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. > > > > Can you supply some specific proposed text for -04? > When do you expect -04? Depending on it, I may be able to. > > > Best, > > -- > > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > Thanks again for your useful review comments! > > > > -- Mike > > > -- 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
