On Tue, Aug 11, 2015 at 5:30 PM, John Bradley <ve7...@ve7jtb.com> wrote: > I think Brian also argued that flattening would save a registry, and be > easier to process in the default case. > > I don’t really by the argument that having a cnf object makes it that much > harder to process. I think it is stylistically better json to keep the > elements together so that they can be extended separately from the main JWT > claim space. > > Having two confirmation elements could be done flat but I think that gets > even more messy. > > I understand Brians arguments, however prefer having a cnf object with no > array. > > I have to agree with his observation that we should keep away from promoting > multiple confirmation elements as it adds to complexity and interoperability > issues. > Better to make one work well and allow for an extension for those cases that > really need it. > > I think the SAML subject confirmation is too complex for most people who use > it to really understand all the combinations of options.
Thanks to all for the additional discussion/explanation. If others want to weigh in, please do so. Best regards, Kathleen > > John B. > > > On Aug 11, 2015, at 1:41 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > 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 <michael.jo...@microsoft.com> > 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:kathleen.moriarty.i...@gmail.com] >> 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 <michael.jo...@microsoft.com> >> 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:oauth-boun...@ietf.org] 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 >> > OAuth@ietf.org >> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
