Re: [OAUTH-WG] JWT PoP Key Semantics WGLC followup 3 (was Re: confirmation model in proof-of-possession-02)

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> wrote:
>
> Some replies inline but the gist is that I disagree.
>
> On Thu, Jul 30, 2015 at 2:17 PM, Mike Jones <[e-mail]>
> 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:[e-mail]] *On Behalf Of *Brian
>> Campbell
>> *Sent:* Thursday, July 30, 2015 11:29 AM
>> *To:* Nat Sakimura <[e-mail]>
>> *Cc:* oauth <[e-mail]>
>> *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 <[e-mail]>
>> wrote:
>>
>> +1
>>
>> =nat via iPhone
>>
>>
>> 2015/03/23 11:07、Brian Campbell <[e-mail]> のメッセージ:
>>
>> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>