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]] 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]<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
