To really support that case where an initial AS/issuer wants to bind to two
presenters, shouldn't the confirmation structure itself allow for multiple
confirmation methods (i.e. be or allow for an array)? I don't actually
think that is needed but the flexibility that's being argued for here would
suggest that rather than renaming a nested structure that only allows for a
single occurrence of each kind of confirmation method.
On Thu, Jul 30, 2015 at 3:14 PM, John Bradley <ve7...@ve7jtb.com> wrote:
> I agree, flattening would be a bad direction.
>
> In Prague I was indicating that there may be more than one presenter for
> an assertion. The first presenter may be the OAuth client who presents it
> to a RS.
>
> That RS itself may also present that token as a client in token exchange
> to get a new access token for another resource.
>
> The initial AS may want to bind that token to two presenters. The second
> AS doing the token exchange also probably only wants to know about the
> proof key for the RS so that it doesn’t mistakenly give the first client a
> token to directly access a backend API.
>
> Trying to find a generic pattern for that is a bit of a trick though.
>
> I think that a single cnf element is enough for most use cases, however
> having cnf and cnf_rs or some other element using the cnf structure is
> probably the best we can do at this point.
>
> John B.
>
> On Jul 30, 2015, at 5:17 PM, Mike Jones <michael.jo...@microsoft.com>
> 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”: …}
> }
>
> 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:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *On
> Behalf Of *Brian Campbell
> *Sent:* Thursday, July 30, 2015 11:29 AM
> *To:* Nat Sakimura <sakim...@gmail.com>
> *Cc:* oauth <oauth@ietf.org>
> *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 <sakim...@gmail.com> wrote:
>
> +1
>
> =nat via iPhone
>
>
> 2015/03/23 11:07、Brian Campbell <bcampb...@pingidentity.com> のメッセージ:
>
> 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
> OAuth@ietf.org
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
