Replies inline… From: OAuth [mailto:[email protected]] 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 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. 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. 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. 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.) 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. 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. 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. 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. 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”. 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”. 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. 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”. 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. 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. 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. 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. 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. 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.) 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? Best, -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en Thanks again for your useful review comments! -- Mike
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
