Thanks, John! On Wed, Nov 25, 2015 at 4:41 PM, John Bradley <[email protected]> wrote: > I prefer the new wording. > > However the last part could be clearer. >> use be implemented by recipients. > > Or perhaps the blunter “Recipients only understanding bearer tokens may > accept JWT containing “cnf” elements if all the other required claims are > valid. It is important for security to audience restrict tokens using the > JWT “aud claim. The “cnf” claim MUST NOT be used as a pseudo audience > restriction.”
More explicit text like this is is more helpful in my opinion. Kathleen > > Looking at the comments, I get the feeling that some people might think that > cnf may restrict what endpoints can receive the token (because of the key > distribution) it only allows endpoints that should receive the token to > reject ones that come from entities who don’t possess the correct > confirmation. > > John B. > >> On Nov 25, 2015, at 12:25 AM, Mike Jones <[email protected]> wrote: >> >> Rather than elaborating, having looked at the text we're discussing again, >> I'm going to counter-propose that we instead simplify - sticking only to the >> point that the paragraph is intending to get across. Would it work for you >> to simplify the current text: >> >> "A recipient might not understand the cnf claim, in which case it will >> typically be ignored. Unless this is acceptable behavior, applications that >> need the proof-of-possession keys communicated with it to be understood and >> processed must require that the parts of this specification that they use be >> implemented." >> >> to this simpler text? >> >> "A recipient might not understand the cnf claim. Applications that need >> the proof-of-possession keys communicated with it to be understood and >> processed must require that the parts of this specification that they use be >> implemented." >> >> The "must ignore" topic is already addressed in the second paragraph of 3.1 >> (and with exactly the semantics as the rest of JWT), and so doesn't have to >> be re-raised here, as it currently is. Re-raising it is clearly a point of >> distraction. >> >> For what it's worth, I don't remember any DISCUSSes on this topic (although >> it's possible that your memory is better than mine on this point). >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:[email protected]] >> Sent: Tuesday, November 24, 2015 7:14 PM >> To: Mike Jones <[email protected]> >> Cc: [email protected] >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession >> >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones <[email protected]> >> wrote: >>> Fair question about the use of "typically". The reason it's there is that >>> this language in JWT [RFC 7519] Section 4 does permit applications to >>> require that JWTs with not-understood claims be rejected, rather than >>> ignored, even though that's not the default behavior: >>> >>> The set of claims that a JWT must contain to be considered valid is >>> context dependent and is outside the scope of this specification. >>> Specific applications of JWTs will require implementations to >>> understand and process some claims in particular ways. However, in >>> the absence of such requirements, all claims that are not understood >>> by implementations MUST be ignored. >>> >>> So when not understood, "cnf" would typically be ignored, but might not be. >> >> I find that confusing and am now thinking this came up in a discuss as well >> during the review for 7519, didn't it? Can you elaborate int eh security >> considerations section a bit more, otherwise this text appears to be >> conflicting and even with what you intend, it's confusing for implementers >> and will lead to issues with interoperability. >> >> Thanks, >> Kathleen >> >> >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:[email protected]] >>> Sent: Tuesday, November 24, 2015 6:41 PM >>> To: Mike Jones <[email protected]> >>> Cc: [email protected] >>> Subject: Re: [OAUTH-WG] AD review of >>> draft-ietf-oauth-proof-of-possession >>> >>> Hi Mike, >>> >>> Thanks for the quick turn-around. Just one more comment on my comments. >>> >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones <[email protected]> >>> wrote: >>>> Thanks for your review comments, Kathleen. Responses are inline below... >>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:[email protected]] On Behalf Of Kathleen >>>>> Moriarty >>>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>>> To: [email protected] >>>>> Subject: [OAUTH-WG] AD review of >>>>> draft-ietf-oauth-proof-of-possession >>>>> >>>>> Hi, >>>>> >>>>> Thank you all for your work on this draft! I just have a few questions: >>>>> >>>>> 1. Security considerations section says: >>>>> >>>>> "All of the normal security issues, especially in relationship to >>>>> comparing URIs and dealing with unrecognized values, that are >>>>> discussed in JWT [JWT] also apply here." >>>>> >>>>> I find that to be odd phrasing that would likely be picked up in >>>>> subsequent reviews. Please remove the word "normal" so that all of >>>>> the security issues discusses in JWT are included. Are there other >>>>> 'normal considerations in addition to those in JWT that need to be >>>>> listed? The phrasing reads as if that may the case and would be >>>>> better to include them all or pointers or change the phrasing. >>>> >>>> You're right. I removed this awkward wording. >>>> >>>>> 2. Also in the security considerations section, >>>>> >>>>> "A recipient may not understand the newly introduced "cnf" claim and >>>>> may consequently treat it as a bearer token." >>>>> >>>>> What is the proper handling requirement when an unknown claim is >>>>> present? Section 3.1 says: >>>>> "When a recipient receives a "cnf" claim with a >>>>> member that it does not understand, it MUST ignore that member." >>>>> >>>>> Is this why it is treated as a bearer token rather than being >>>>> rejected? Is this really the action you want to see with cnf? Why >>>>> isn't there an error and a resend as a bearer token so that parties >>>>> understand (or have an opportunity to understand) that there were issues? >>>>> >>>>> Then the following text in the security section says: >>>>> "While this is a >>>>> legitimate concern, it is outside the scope of this specification, >>>>> since demonstration the possession of the key associated with the >>>>> "cnf" claim is not covered by this specification. For more >>>>> details, >>>>> >>>>> How is this outside of the scope of this draft? cnf is defined in >>>>> this draft, so handling should be covered in this draft. A pointer >>>>> to the POP architecture draft is not helpful as it is not defined >>>>> there, it's covered int his draft. Should this text just be removed >>>>> and replaced with more explicit handling information int he body of this >>>>> draft? >>>> >>>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not >>>> understood must be ignored unless otherwise specified by the application. >>>> This allows new claims to be dynamically added without breaking existing >>>> applications. For the same reason, I have incorporated this language >>>> about understanding claims from 7519, but having it be about understanding >>>> confirmation members. Ultimately, what features must be implemented are >>>> always up to the application, just as with JWT claims. >>> >>> The new text in Section 3.1 looks good. I'm not sure why the word >>> "typically" appears int he new text of the security considerations section >>> though after reading the new text in 3.1. Wouldn't it just be ignored >>> since 3.1 now says: >>> >>> "However, in the absence of such requirements, >>> all confirmation members that are not understood by implementations >>> MUST be ignored." >>> >>> Thanks, >>> Kathleen >>> >>> >>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> Thanks again, >>>> -- Mike >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
