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
