Token binding might be a bad example. I can’t see why you would need something separate unless you are trying to do something like message signing and token binding. I guess that is theoretically posable.
Typically I think token binding would use the normal cnf containing a JWK with the public key. The difference between token binding and mutual TLS is in the presentment one is TLS client auth and the other is a signature over the tls unique in a header. I think multiple cnf methods for the same presenter like SAML is overkill. However the ability to re-use the cnf structure for people who want something custom seems reasonable (we couldn't stop them anyway) John B. > On Jul 30, 2015, at 7:40 PM, Brian Campbell <[email protected]> > wrote: > > Some replies inline but the gist is that I disagree. > > On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones <[email protected] > <mailto:[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”: …} > > } > > > > > That presumes token binding will use the same confirmation methods. But I'd > imagine that the Token Binding ID would somehow be used to signal > confirmation. So I'd be surprised if it ends up looking like that. The jwe > member of the cnf claim defiantly wouldn't apply. > > It also presumes that you'd want cnf and tokbnd in the same JWT, which > doesn't really make sense to me. This draft wants to establish a registry for > JWT Confirmation Methods but a token binding confirmation would be a > different claim? > > > > 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. > > > Again that presumes token binding will use the same confirmation methods, > which I think it unlikely. > > I suspect it'd be more like cjwk, cjwe, ckid, and ctbd. > > And a cnf with nested structure would need a tbd or tokbnd member defined and > registered. > > > > > 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. > > > You can still have a shared routine for handling things that are the same. > But with a nested structure you have to dig into the nesting. > > > > > 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 personally don't find that convincing. It depends on how someone thinks > about it. > > > > > 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. > > > It was an informal discussion that was largely about something else. > > > > > 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? > > > That's not at all what I'm driving at. > > If you believe that there's need for multiple confirmation structures with > the exact same syntax and meaning, I suppose that would be a useful addition. > But if you really believe that, the structure itself should probably be > adjusted to allow for multiples. I'm skeptical that it'll ever be needed. > > > > > 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. > > > I can see both sides of readability. I don't see the flexibility. > > And once you prefix the names, you lose most of the space savings anyway. > > > Depends on how you prefix them or otherwise name things. You've chosen long > prefixes to make your point but it wouldn't have to be that way. > > > > > Best wishes, > > -- Mike > > > > From: OAuth [mailto:[email protected] <mailto:[email protected]>] > On Behalf Of Brian Campbell > Sent: Thursday, July 30, 2015 11:29 AM > To: Nat Sakimura <[email protected] <mailto:[email protected]>> > Cc: oauth <[email protected] <mailto:[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] > <mailto:[email protected]>> wrote: > > +1 > > =nat via iPhone > > > 2015/03/23 11:07、Brian Campbell <[email protected] > <mailto:[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] <mailto:[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
