Sorry for a tardy reply. You are right. My +1 was for flattening. Also, my comment around 3.4 was not an implicit endorsement for having structured cnf claim. I was merely pointing out that it is a bad practice to use a defined term before it being defined.
Nat 2015-08-12 1:41 GMT+09:00 Brian Campbell <[email protected]>: > I took Nat's "+1" as support for flattening things into individual claims > like "cjwe", "cjwk" and "ckid". Maybe that's just confirmation bias on my > part. But it'd be interesting to get Nat's actual opinion as apposed to his > assumed or implied opinion. Nat? > > It seems to me that it's really a question of aesthetics because the > arguments in favor of the structured claim approach that cite flexibility > or the ability to "carry more than one conformation key or key descriptor" > are erroneous. Both approaches can carry more than one as long as they are > different types and both can achieve additional flexibility by adding new > names for things (all of which, I suspect, will be very unlikely to happen > anyway). My suggesting to flatten was an attempt at simplification. And I > do think it would simplify. But that's only my opinion. If folks prefer the > aesthetics and structure of the "cnf" as currently defined and feel it's > easier to comprehend, I can live with that. All the rest of the > justification, however, just obscures things. > > To Kathleen's request, the thread index is > http://www.ietf.org/mail-archive/web/oauth/current/threads.html#14854 and > starts with > http://www.ietf.org/mail-archive/web/oauth/current/msg14854.html. The > consensus therein seems to be to leave things as they are (though only > John, Mike and I participated and I was the minority opinion). > > > > > > On Tue, Aug 11, 2015 at 7:29 AM, Mike Jones <[email protected]> > wrote: > >> Brian's note contained two suggestions, which I'll address separately. >> >> The first was to have "cnf" contain an array of values rather than >> individual values. But even he said "I'm not sure the extra complexity is >> worth it though. I've rarely, if ever, seen SAML assertions that make use >> of it." I took Nat's +1 as an agreement that the complexity of array >> values isn't worth it, and shouldn't be introduced. No one else has since >> spoke up for having the "cnf" claim contain array values, and Brian only >> mentioned it as a possibility but dismissed it as too complex. >> >> The second was to not have the "cnf" claim at all, but instead to flatten >> things so that the "cnf" elements would become individual claims, along the >> lines of "cnf_jwk", "cnf_jwe", "cnf_kid", etc. This was discussed in the >> thread " [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: >> confirmation model in proof-of-possession-02)" - for instance, John >> Bradley's message >> http://www.ietf.org/mail-archive/web/oauth/current/msg14859.html in >> which he stated that "flattening would be a bad direction". Nat also >> implicitly endorsed keeping "cnf" in his WGLC review comments in >> http://www.ietf.org/mail-archive/web/oauth/current/msg14418.html, in his >> comment "Since 'cnf' appears before 3.4, it may be better to bring 3.4 at >> the front." He suggested changing the location of "cnf" in the document - >> not removing it, as Brian's flattening suggestion would have done. >> >> Tony Nadalin also earlier had spoken about the need to support use cases >> in which there would be multiple proof-of-possession keys. Among other >> places, he alluded to this in his note >> http://www.ietf.org/mail-archive/web/oauth/current/msg14305.html in >> which he wrote "Is this proposal also limited to a single key for both >> asymmetric and symmetric?". This is pertinent because as I wrote in the >> first thread mentioned at >> http://www.ietf.org/mail-archive/web/oauth/current/msg14856.html, "Part >> of the reasoning for using a structured confirmation claim, rather than >> flattening the confirmation claim into the top-level JWT claims set, is >> that a JWT may carry more than one conformation key or key descriptor" - >> per Tony's use cases. John Bradley's note agreeing that flattening would >> be a bad direction was a response to that. >> >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:[email protected]] >> Sent: Tuesday, August 11, 2015 6:00 AM >> To: Mike Jones >> Cc: Brian Campbell; oauth >> Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02 >> >> On Tue, Aug 11, 2015 at 12:08 AM, Mike Jones <[email protected]> >> wrote: >> > There didn’t seem to be support for having cnf contain array values. >> > Instead, as discussed in the thread “[OAUTH-WG] JWT PoP Key Semantics >> > WGLC followup 3 (was Re: confirmation model in >> > proof-of-possession-02)”, if different keys are being confirmed, they >> > can define additional claims other than “cnf” using the same structure >> > as “cnf” to represent those confirmations. Indeed, those other claims >> > could be array-valued, if appropriate. The reasons for having a >> > structured “cnf” claim, rather than a set of flattened claim values, >> were also discussed in that thread. >> >> Can you send the link to that thread and the result if it differs from >> what Brian and Nat agree on? I'd like to know that there is enough to >> determine consensus on this point. >> >> Thanks! >> Kathleen >> > >> > >> > >> > Thanks >> > again, >> > >> > -- Mike >> > >> > >> > >> > From: OAuth [mailto:[email protected]] On Behalf Of Brian >> > Campbell >> > Sent: Monday, March 23, 2015 9:07 AM >> > To: oauth >> > Subject: [OAUTH-WG] confirmation model in proof-of-possession-02 >> > >> > >> > >> > This is mostly about section 3.4 but also the whole draft. >> > >> > >> > If "cnf" is intended to analogous to the SAML 2.0 SubjectConfirmation >> > element, it should probably contain an array value rather than an >> > object value. SAML allows not just for multiple methods of confirming >> > but for multiple instances of the same method. IIRC, only one >> > confirmation needs to be confirmable. >> > >> > I'm not sure the extra complexity is worth it though. I've rarely, if >> > ever, seen SAML assertions that make use of it. >> > >> > If the intent is just to allow for different kinds of confirmation, >> > couldn't the structure be pared down and simplified and just have >> > individual claims for the different confirmation types? Like "cjwk" >> > and "ckid" or similar that have the jwk or kid value respectively as >> the member value. >> > >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i >> > etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40mi >> > crosoft.com%7ca8e38b0ea0334d11e50008d2a24cc573%7c72f988bf86f141af91ab2 >> > d7cd011db47%7c1&sdata=9ukCTugBdbhTVriEoH3HdfMIloD%2fTHYY%2bdPOpQSs7x4% >> > 3d >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
