Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115446A5608@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 2 Apr 2014 09:44:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AEB91A8-B99B-4263-AB26-353F3ED27288@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com>
 <255B9BB34FB7D647A506DC292726F6E115446A5608@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LDBT-u0-e8ckK8mtsLyDWzXuf-0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens
 (JWTs)
Precedence: list

Thanks for the feedback.

inline
On Apr 2, 2014, at 1:50 AM, Manger, James =
<James.H.Manger@team.telstra.com> wrote:

>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00
>=20
>=20
> A new registry for "cnf" members is a bit strange. A JWT Claim Set has =
so far been a flat structure, with metadata such expiry date "exp" =
alongside claims such as "given_name". This spec starts introducing =
structure by wrapping members in a "cnf" (confirmation) object. It is =
not clear to me which new things would go in "cnf" versus going in to =
the top-level of the JWT claim set. Both locations have a "MUST ignore" =
policy for unrecognized members.

This is the first draft so this needs to be fleshed out.  The idea is to =
have a single object that contains what in SAML would be the subject =
confirmation information.   I expect hat the protocols using this are =
going to determine what claims need to go in cnf.  =20

As an example for bearer tokens there might be an expirey time for =
presentment that is separate from the tokens lifetime as represented by =
"exp" at the top level.
This may not be a great example as people in general don't understand =
the difference between the two exp in SAML:)  =20

But in general cnf contains claims that are required to confirm that the =
presenter is the subject/issuer or a designated agent.

>=20
>=20
>   "(In some applications, the subject identifier will be relative
>   to the issuer identified by the "iss" (issuer) claim.)"
>=20
> This isn=92t very helpful as it gives no hint about when this is or =
isn=92t the case. I guess this is just rewording a flaw from JWT.

This is one thing we have been wrangling over the wording of.

In the simple case where there is a "sub" then the key represents the =
proof key of the presenter or a authorized agent on there behalf.

There are some slippery bits even in that as it is the recipient that is =
trusting the issuer to put in the correct cnf information. Especially in =
cases where there may be multiple hops the key may be that of a RS that =
the user has no direct trust relationship with.

In the case where there is no subject, I tend to think of the JWT as =
having a implicit subject that is the issuer as that is really the only =
thing the claims could be about in the absence of a explicit subject.
A JWT without a subject could have a claim about a user that is logged =
into me but the me is the issuer.

So as in the case of there being no explicit subject the cnf is of the =
iss or a agent it has designated.

In principal if a intermediary receives the token and sends it to a STS =
like service the resulting JWT would then have the STS as the iss and =
the original iss as the sub.  Though that is outside of this spec.

Trying to come up with a simple explanation without dragging a bunch of =
other stuff in to the spec is not easy.

Perhaps something more like the cnf must evaluate to true for the =
presenter of the JWT otherwise the token is not being presented by a =
party authorized by the issuer, given that the recipient's primary trust =
relationship is with the issuer.

Trying to say who the presenter is may just be too confusing at this =
level.

Thoughts and wording input appreciated.


>=20
>=20
> Could the JWE example please include a "kid"? The recipient needs to =
know which key to use to decrypt the message. JWS says we SHOULD do this =
[JWS =A76 2nd paragraph]. [P.S. Weren=92t we going to include "kid" is =
almost all the examples in JWE?]

Yes it should include a "kid"
>=20
> You may as well drop the "cty":"jwk+json" member as this is implied by =
the JOSE message being the value of a "jwk" member.
>=20
It may be useful to libraries processing the JWE.

>=20
> OpenID Connect has already defined a "sub_jwk" field that performs a =
similar role to "cnf":{"jwk"}.
> =
[http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse]

As you have pointed out connect self Issued needs an errata to address a =
problem anyway.

They are similar though the self issued case is more like a JWT that =
would be used as a proof mechanism rather than as a pop token itself.

Perhaps there is a case where the iss is using it's signing key for =
signing the token and via tls channel binding for presentment as an =
example.=20

The connect case doesn't require a presentment proof so is a bit =
different.   =20

I take your point and will think about it a bit more.


>=20
>=20
> Perhaps the biggest security consideration is missing: "cnf" may be =
ignored. A recipient that doesn't understanding "cnf" is likely to =
accept a JWT as a bearer token without doing any proof-of-possession.
>=20

I think the protocol using the JWT would likely be where the requirement =
would be enforced along with the presentment mechanism.

John B.

> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth