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
