Re: [OAUTH-WG] confirmation model in proof-of-possession-02
I would rather just keep the cnf claim rather than flatten the structure since we are already using the cnf in production with the XBOX One. We are also using multiple conformation keys and using the cnf claim makes it easier to have multiple confirmation keys (by just defining a new claim to hold each confirmation key, using the same structure as cnf). -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty Sent: Tuesday, August 11, 2015 3:00 PM To: John Bradley ve7...@ve7jtb.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02 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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ie tf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fthreads.html%2314854d ata=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983c e7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=q4MCqdNwwxQ2WqZ1CAWABG IdUlDENFM0NvQ4SYEUMDY%3d and starts with https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14854.html.data=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=TGx59LZoSrJpLY0rrViJzO6KJnCTrqr%2bYy57NA9YH8E%3d 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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.i etf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14859.htmldata=0 1%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
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 bcampb...@pingidentity.com: 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
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
Seems the consensus here is clearly in favor of keeping the cnf claim as it is. I'll let the flattening suggestion go gentle into that good night. On Tue, Aug 18, 2015 at 1:33 PM, Anthony Nadalin tony...@microsoft.com wrote: I would rather just keep the cnf claim rather than flatten the structure since we are already using the cnf in production with the XBOX One. We are also using multiple conformation keys and using the cnf claim makes it easier to have multiple confirmation keys (by just defining a new claim to hold each confirmation key, using the same structure as cnf). -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty Sent: Tuesday, August 11, 2015 3:00 PM To: John Bradley ve7...@ve7jtb.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] confirmation model in proof-of-possession-02 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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ie tf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fthreads.html%2314854d ata=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983c e7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=q4MCqdNwwxQ2WqZ1CAWABG IdUlDENFM0NvQ4SYEUMDY%3d and starts with https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg14854.html.data=01%7c01%7ctonynad%40microsoft.com%7cc8935ea677b848a37dd308d2a2983ce7%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=TGx59LZoSrJpLY0rrViJzO6KJnCTrqr%2bYy57NA9YH8E%3d 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
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
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 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 mailto: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 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 mailto:OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i etf.org http://etf.org/%2fmailman%2flistinfo%2foauthdata=01%7c01%7cMichael.Jones%40mi crosoft.com http://crosoft.com/%7ca8e38b0ea0334d11e50008d2a24cc573%7c72f988bf86f141af91ab2 d7cd011db47%7c1sdata=9ukCTugBdbhTVriEoH3HdfMIloD%2fTHYY%2bdPOpQSs7x4% 3d -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
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%2foauthdata=01%7c01%7cMichael.Jones%40mi crosoft.com%7ca8e38b0ea0334d11e50008d2a24cc573%7c72f988bf86f141af91ab2 d7cd011db47%7c1sdata=9ukCTugBdbhTVriEoH3HdfMIloD%2fTHYY%2bdPOpQSs7x4% 3d -- Best regards, Kathleen
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
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
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
-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%2foauthdata=01%7c01%7cMichael.Jones%40mi crosoft.com%7ca8e38b0ea0334d11e50008d2a24cc573%7c72f988bf86f141af91ab2 d7cd011db47%7c1sdata=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
Re: [OAUTH-WG] confirmation model in proof-of-possession-02
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. 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.4https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#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://www.ietf.org/mailman/listinfo/oauth
