Thanks for a quick reply, Justin. On Tue, Nov 24, 2015 at 1:48 PM, Justin Richer <[email protected]> wrote: > I suggest removal of the reference to bearer tokens in this section, since > that seems to suggest that this is what the RS should do in such a case. > What’s really going to happen is that an RS is going to get a request with > this token and it’s going to have to figure out how to deal with it. If > there’s a signature (like in http-message-signing) then it’s going to need to > find the key. If it can’t read the key out of the cnf claim then it won’t be > able to validate the signature and won’t process the message. If that’s the > case then this RS can’t accept this token.
If this is the case, handling text would be helpful in the draft. > > This has nothing to do with bearer tokens vs. PoP tokens. It’s not really any > different from an RS accepting JWT bearer tokens needing to be able to parse > or process the JWT bearer token to figure out what it’s good for. Right? If this is the case, new text would be helpful, it's a little confusing as-is and I would assume what you assume above too. Hopefully, new text is a simple fix as I'd like to start IETF last call soon on this and the architecture draft (as in this week soon). Thanks, Kathleen > > — Justin > >> On Nov 24, 2015, at 12:44 PM, Kathleen Moriarty >> <[email protected]> wrote: >> >> 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. >> >> 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? >> >> Thanks! >> >> -- >> >> 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
