Yes the token binding token has the public key so yes you could send the JWK thumbprint of the key in the cnf method vs sending the JWK again to save space. That is something we can add later as a confirmation method.
I prefer the structured approach even if it takes another registry. I think it is easer to understand. I agree that we don’t want to oversell the relationship to SAML confirmation methods. This is POP confirmation not the more abstract subject confirmation (that has pop as one option). John B. > On Jul 31, 2015, at 3:46 PM, Brian Campbell <[email protected]> > wrote: > > The Token Binding ID already has the public key in it. A normal cnf > containing a JWK with the public key would work. But the whole Token Binding > ID would probably be simpler. Or, if we're gonna make them parse the Token > Binding ID, then a cnf that uses a finger/thumbprint of the key would be more > space efficient as the whole key is already being sent elsewhere. That's all > stuff that can be worked out later though. What I'm trying to express is that > we don't really know what kind of flexibility will be needed and it's not at > all clear that a structured cnf claim gives flexibility. > > > > On Thu, Jul 30, 2015 at 4:52 PM, John Bradley <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
