Some replies inline but the gist is that I disagree.
On Thu, Jul 30, 2015 at 2: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”: …}
>
> }
>
>
>
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]] *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
