Don't get me wrong, I don't think an array is needed at all (and I fear the language in the draft that draws an analogy to SAML is maybe more likely to confuse than help). I just don't buy the argument that the nested structure is so much more flexible for these hypothetical cases.
I seem to be in the minority here though (at least of the few people actually responding). And, while I thought there was room for a nice simplification, it's not something I care to fight (much) about. On Thu, Jul 30, 2015 at 5:00 PM, John Bradley <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> 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:[email protected] <[email protected]>] *On >> Behalf Of *Brian Campbell >> *Sent:* Thursday, July 30, 2015 11:29 AM >> *To:* Nat Sakimura <[email protected]> >> *Cc:* oauth <[email protected]> >> *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 <[email protected]> >> wrote: >> >> +1 >> >> =nat via iPhone >> >> >> 2015/03/23 11:07、Brian Campbell <[email protected]> のメッセージ: >> >> 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 >> [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
