Hi Mike, If the working group is okay with the current text, leave it. What you proposed is exactly the same as what is there. I'll note this point in my ballot as I think you are leaving ambiguity that is not necessary.
After getting far enough on this, I think it was Pete who discussed this with you and he gave up and remained in disagreement. Regards, Kathleen Sent from my iPhone > On Nov 24, 2015, at 10:25 PM, Mike Jones <michael.jo...@microsoft.com> 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:kathleen.moriarty.i...@gmail.com] > Sent: Tuesday, November 24, 2015 7:14 PM > To: Mike Jones <michael.jo...@microsoft.com> > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession > >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones <michael.jo...@microsoft.com> >> 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:kathleen.moriarty.i...@gmail.com] >> Sent: Tuesday, November 24, 2015 6:41 PM >> To: Mike Jones <michael.jo...@microsoft.com> >> Cc: oauth@ietf.org >> 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 <michael.jo...@microsoft.com> >>> wrote: >>> Thanks for your review comments, Kathleen. Responses are inline below... >>> >>>> -----Original Message----- >>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen >>>> Moriarty >>>> Sent: Tuesday, November 24, 2015 9:44 AM >>>> To: oauth@ietf.org >>>> 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 >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> Thanks again, >>> -- Mike >> >> >> >> -- >> >> Best regards, >> Kathleen > > > > -- > > Best regards, > Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
