In my example you don’t really want to treat both the presenters as equivalent. Endpoints receiving the token should be able to tell which presenter gave it to them and apply policy on that.
If you wanted them to be equivalent then an array would work, but that probably adds more confusion. John B. > On Jul 30, 2015, at 7:48 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > To really support that case where an initial AS/issuer wants to bind to two > presenters, shouldn't the confirmation structure itself allow for multiple > confirmation methods (i.e. be or allow for an array)? I don't actually think > that is needed but the flexibility that's being argued for here would suggest > that rather than renaming a nested structure that only allows for a single > occurrence of each kind of confirmation method. > > On Thu, Jul 30, 2015 at 3:14 PM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > I agree, flattening would be a bad direction. > > In Prague I was indicating that there may be more than one presenter for an > assertion. The first presenter may be the OAuth client who presents it to a > RS. > > That RS itself may also present that token as a client in token exchange to > get a new access token for another resource. > > The initial AS may want to bind that token to two presenters. The second AS > doing the token exchange also probably only wants to know about the proof key > for the RS so that it doesn’t mistakenly give the first client a token to > directly access a backend API. > > Trying to find a generic pattern for that is a bit of a trick though. > > I think that a single cnf element is enough for most use cases, however > having cnf and cnf_rs or some other element using the cnf structure is > probably the best we can do at this point. > > John B. > >> On Jul 30, 2015, at 5:17 PM, Mike Jones <michael.jo...@microsoft.com >> <mailto:michael.jo...@microsoft.com>> wrote: >> >> 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, as was >> mentioned in Prague. For instance, imagine that an application is conveying >> an application-level confirmation key using the “cnf” claim and for instance >> a token binding key using a second instance of the confirmation structure, >> say using the “tokbnd” claim. With the current structured approach, you’d >> have: >> >> {… >> “cnf”:{“jwk”: …}, >> “tokbnd”:{“jwk”: …} >> } >> >> If one were to flatten the structure, however, unique claim names would have >> to be produced for the cross-product of each conformation element and each >> confirmation claim. So you’d end up defining and registering these claims >> in the top-level JWT Claims registry: >> cnf_jwk >> cnf_jwe >> cnf_kid >> tokbnd_jwk >> tokbnd_jwe >> tokbnd_kid >> If you add other kind of confirmation keys, things would continue to get >> even sillier. >> >> The code will be simpler if you can have a single shared routine for >> handling confirmation structures rather a separate for handling cnf_jwk, >> cnf_jwe, cnf_kid from the one for handling tokbnd_jwk, tokbnd_jwe, >> tokbnd_kid, etc. >> >> Another reason the structure makes things conceptually simpler is that then >> you can always use the name “kid” to hold a key ID, no matter the context, >> rather than having to use name-your-prefix_kid. The same holds true for >> other elements. >> >> I’m sorry this wasn’t clear in Prague. I know it was mentioned in the >> context of carrying multiple confirmation keys in a JWT, but it went by >> pretty fast. >> >> Based on the discussion in Prague, I believe that we should add language to >> the spec saying that applications can define new claim names other than >> “cnf” to use to represent application-specific confirmation structures that >> have the same syntax as those using the “cnf” name. Would that do the trick >> for you? >> >> By the way, I’m as much in favor of compactness as anyone. Heck – I was one >> of the folks who foisted the short claim names like “iss” on the world! But >> I really do believe that in this case, having structure makes things more >> readable and more flexible, especially since there will be cases where there >> are multiple confirmation structures in the same JWT. And once you prefix >> the names, you lose most of the space savings anyway. >> >> Best wishes, >> -- Mike >> >> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] >> On Behalf Of Brian Campbell >> Sent: Thursday, July 30, 2015 11:29 AM >> To: Nat Sakimura <sakim...@gmail.com <mailto:sakim...@gmail.com>> >> Cc: oauth <oauth@ietf.org <mailto:oauth@ietf.org>> >> Subject: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: >> confirmation model in proof-of-possession-02) >> >> Using individual claims for the different confirmation types would convey >> the same information with a reduced message size, likely simpler >> implementation, and avoid the need to establish a new registry. >> >> Seems like a no-brainer to me but maybe I'm overlooking something? >> >> There hasn't been much discussion that I'm aware of. Nat seemed in favor of >> it (the +1 below). Mike was dismissive of it at the Dallas meeting but >> didn't provide any reasoning (that I understood anyway). >> >> >> On Mon, Mar 23, 2015 at 10:18 AM, Nat Sakimura <sakim...@gmail.com >> <mailto:sakim...@gmail.com>> wrote: >> +1 >> >> =nat via iPhone >> >> 2015/03/23 11:07、Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> のメッセージ: >> >> This is mostly about section 3.4 >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-02%23section-3.4&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2dHZxIhDc2jtu1krNFIccKamceZvM4%2b7Yw0hJGA6WcY%3d> >> 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://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c8abba73f10ae4e3ddcff08d2990cd3bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jwMvoc50hKttPr1u5gwWLmmCI9k3zumK8RtzWR2F7w0%3d> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
