Thanks again for your detailed review, Nat. The remainder of the issues you raised are addressed in the -04 draft<http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04>. Replies are inline prefixed by Mike> …
From: Nat Sakimura [mailto:sakim...@gmail.com] Sent: Tuesday, August 18, 2015 9:00 PM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] Review Comments for draft-ietf-oauth-proof-of-possession-02 Inline: 2015-08-11 14:12 GMT+09:00 Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>: Replies inline… From: OAuth [mailto:oauth-boun...@ietf.org<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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-architecture-01&data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3S7krqi0KCDTpgN8bOMXakqMNwsxVka24mvUqB8uWjE%3d> 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. Mike> I have added this to the introduction in response to your comment: “See <xref target="I-D.ietf-oauth-pop-architecture"/> for a further discussion of key confirmation.” 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]. Mike> As noted earlier, I have added this to the introduction in response to your comment: “See <xref target="I-D.ietf-oauth-pop-architecture"/> for a further discussion of key confirmation.” I did not reference a specific section number because ietf-oauth-pop-architecture has not yet entered the RFC Editor queue, and so the section number may change. 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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-rjwtprof-04&data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y8Ty0Qm8KkgiI%2bzD86cmMMikbEZuAbP2U3zX7MhRr7E%3d> 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. Mike> “Presenter” is no more generic than “Issuer” or “Recipient”. All are standard terms for these kinds of flows, so I’m reluctant to invent new terminology. By design and by definition, a rogue party who does not hold the key is not a presenter. (In the same way, a party who creates a JWT and signs a forged “iss” value with a key other the named issuer’s keys is not the issuer.) The standard term for such a party is “the attacker”; we haven’t lost the word for such a party. 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. Mike> I’ve deleted this sentence from the draft “The presenter may be the issuer or a party distinct from the issuer.” It seems to have been causing more confusion than clarity. 3. Proof-Of-Possession 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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-03%23section-3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=coTzyGHtu%2baIZy4CphYTHcrFXZtcwnxtXulpT55btME%3d> 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. Mike> Fair point. I’ve added this text to address your suggestion: “The content of the <spanx style="verb">kid</spanx> value is application specific. For instance, some applications may choose to use a JWK Thumbprint <xref target="JWK.Thumbprint"/> value as the <spanx style="verb">kid</spanx> value.” 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. Mike> The more I thought about this, the more I agreed that “jku” was needed to enable PoP keys to be passed by reference. Please review the text adding “jku” at http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04#section-3.5. 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. Mike> Done. The former 3.4 is now 3.1. 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. Mike> Done – thanks! 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. Mike> I wrote a Privacy Considerations section, addressing the use of confirmation keys as correlation handles. Best, -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00R1M%2fvqVi6wrk5VWHVAaNu2QZwBoXMiiueGWw8kJWI%3d> @_nat_en Thanks again for your useful review comments! -- Mike -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c619743bacdc34c1bc67408d2a84ab41b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00R1M%2fvqVi6wrk5VWHVAaNu2QZwBoXMiiueGWw8kJWI%3d> @_nat_en Thanks again, Nat! -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
