Message-ID: <53577C32.5060604@gmx.net>
Date: Wed, 23 Apr 2014 10:39:14 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>,
 oauth mailing list <oauth@ietf.org>
References: <1373E8CE237FCC43BCA36C6558612D2AA347D1@USCHMBX001.nsn-intra.net>
 <4E1F6AAD24975D4BA5B16804296739439A0A956A@TK5EX14MBXC286.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439A0A956A@TK5EX14MBXC286.redmond.corp.microsoft.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="PSPTctst4rODBX7iGeVHMPIPdP0NShqWG"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HQu9bO_KjaShzfnCz90pKAp9dxA
Subject: Re: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PSPTctst4rODBX7iGeVHMPIPdP0NShqWG
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Mike,

thanks for the clarifications. My comments are addressed.

Ciao
Hannes


On 03/03/2014 11:22 PM, Mike Jones wrote:
> Hi Hannes,
>=20
> =20
>=20
> My replies to your comments follow in-line.  Thanks again for writing
> these up.
>=20
> =20
>=20
>                                                             -- Mike
>=20
> =20
>=20
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, September 12, 2013 1:07 AM
> To: oauth mailing list
> Subject: [OAUTH-WG] My review of draft-ietf-oauth-json-web-token-11
>=20
> =20
>=20
> Hi Mike, Hi all,
>=20
> =20
>=20
> As part of preparing the shepherd write-up I have read the draft and
> here are a few comments.
>=20
> =20
>=20
> In general, the draft looks good. The comments are fairly minor.
>=20
> =20
>=20
> 1. Section 4: JWT Claims
>=20
> =20
>=20
> In the first paragraph you write:
>=20
> "
>=20
> The Claim Names within a JWT Claims Set MUST be unique; recipients MUST=

> either reject JWTs with duplicate Claim Names or use a JSON parser that=

> returns only the lexically last duplicate member name "
>=20
> =20
>=20
> I think what you want to write here is that the sender of a JWT must
> ensure that the claims are unique. If a JWT is, however, received with
> non-unique claims then some decision must be taken. You list two choice=
s
> and I am wondering why not just have one. Let's just reject the JWT if
> that happens to ensure consistent behavior.
>=20
> =20
>=20
> This was extensively discussed within JOSE and the language used is the=

> same.  Ideally, yes, we=92d reject duplicate names, but both the old an=
d
> new JSON specs allow duplication, so if we=92re to use existing deploye=
d
> parsers, that isn=92t really a practical option.  (We used to require
> rejection of duplicate names, but objections were raised to that.)
>=20
> =20
>=20
> I believe it might be good to clarify that unique here means that claim=
s
> may appear more than once in a JWT but you are concerned about having
> two claims that actually have a different semantic. Correct?
>=20
> =20
>=20
> No, the issue is that either parsers will only return one (they will
> overwrite each other) or duplicates will cause a parsing error.=20
> Therefore, for things to always work regardless of parser, producers
> can=92t include any duplicates.
>=20
> =20
>=20
> You write: "However, in the absence of such requirements, all claims
> that are not understood by implementations SHOULD be ignored."
>=20
> =20
>=20
> The 'SHOULD' is not good enough here. Either you ignore claims that you=

> don't understand or you do something else. Since there does not seem to=

> be a way to declare claims as "critical" to understand I suggest to tur=
n
> this into a MUST.
>=20
> =20
>=20
> Agreed.  I made this change in -18.
>=20
> =20
>=20
> With every claim you add "Use of this claim is OPTIONAL.". I would
> suggest to move that sentence to the front and avoid repeating it with
> every claim. In fact you have that necessary sentence currently in
> Section 4.1 "None of the claims defined below are intended to be
> mandatory to use, but rather, provide a starting point for a set of
> useful, interoperable claims."
>=20
> =20
>=20
> For what it=92s worth, Jim Schaad had requested the opposite =96 that t=
he
> =93OPTIONAL=94 statements be on a per-name basis =96 so each definition=
 could
> be easily read in isolation.
>=20
> =20
>=20
> Since you describe the "use" there is obviously the question about the
> "implementation". So, what claims in this document are mandatory to
> implement? All? None?
>=20
> =20
>=20
> None.  It=92s up to the application what claims are MTI for its use cas=
e.=20
> I added text clarifying this.
>=20
> =20
>=20
> Claim Types: You distinguish between three types of claims, namely
> Reserved Claim Names, Public Claim Names, and Private Claim Names.
>=20
> =20
>=20
> - Reserved claims are those that are registered with IANA.
>=20
>  - Public Claims are (interestingly enough) also registered via IANA or=

> use a Collision Resistant Namespace.
>=20
>  - Private Claims are those that may produce collisions
>=20
> =20
>=20
> Clear I would suggest to change the definition of a public claim. Let's=

> just call the claims that are registered via IANA reserved claims.
>=20
> =20
>=20
> =93Reserved=94 was changed to =93registered=94, both here and in JOSE, =
as a
> result of review comments from both working groups.
>=20
> =20
>=20
> I also wonder why we need private claims at all when it is so easy to
> construct public claims?
>=20
> =20
>=20
> In practice, people will use unregistered names in some contexts.=20
> (There was a 1/2 hour presentation in AppsAWG today about this very
> thing!)  Given we really can=92t prevent this and it will happen, it=92=
s
> better to clearly describe the downsides and alternatives than to
> pretend that private names won=92t be used.  At least this way, people
> will have been warned about the consequences of their choices.
>=20
> =20
>=20
> Section 4.1.1: "iss" (Issuer) Claim
>=20
> =20
>=20
> You write:
>=20
> "
>=20
> The iss (issuer) claim identifies the principal that issued the JWT. Th=
e
> processing of this claim is generally application specific.
>=20
> "
>=20
> =20
>=20
> Would it be useful to say what people use this claim for. It might also=

> be useful to indicate that this value cannot be relied on for any trust=

> or access control decisions without proper cryptographic assurance. I
> can already see people who base their security decisions on this value
> without any relationship to the actual crypto of the JWT. So, one might=

> wonder what the relationship of the crypto and the iss claim is.
>=20
> =20
>=20
> I added language about making trust decisions in the Security
> Considerations section.  Did you have particular language in mind about=

> what the claim is used for, beyond stating that it identifies the issue=
r?
>=20
> =20
>=20
> Section 4.1.3: "aud" (Audience) Claim
>=20
> =20
>=20
> You write:
>=20
> "
>=20
> The aud (audience) claim identifies the audiences that the JWT is
> intended for.
>=20
> "
>=20
> =20
>=20
> That's not a good description. You could instead write: "The aud
> (audience) claim identifies the recipient the JWT is intended for."
>=20
> =20
>=20
> Agreed =96 done.
>=20
> =20
>=20
> You write:
>=20
> "
>=20
> In the special case when the JWT has one audience, the aud value MAY be=

> a single case sensitive string containing a StringOrURI value.
>=20
> "
>=20
> =20
>=20
> Shouldn't this read:
>=20
> "
>=20
> In the special case when the JWT has one audience, the aud value is a
> single case sensitive string containing a StringOrURI value.
>=20
> "
>=20
> =20
>=20
> No =96 because either =93aud=94:=94foo=94 or =93aud=94:[=93foo=94] are =
legal and mean the
> same thing.
>=20
> =20
>=20
> Section 4.1.8. "typ" (Type) Claim
>=20
> =20
>=20
> You write:
>=20
> "
>=20
> The typ (type) claim MAY be used to declare a type for the contents of
> this JWT Claims Set in an application-specific manner in contexts where=

> this is useful to the application. The typ value is a case sensitive
> string. Use of this claim is OPTIONAL.
>=20
> =20
>=20
> The values used for the typ claim come from the same value space as the=

> typ header parameter, with the same rules applying.
>=20
> "
>=20
> =20
>=20
> I believe the first sentence should say: "The typ (type) claim is used
> to declare a type for the contents of this JWT Claims Set ....". I don'=
t
> understand what the "MAY" here was supposed to indicate since if it doe=
s
> not declare the type of the claims then what else does it do?
>=20
> =20
>=20
> Why is the typ claim actually there when there is already the same clai=
m
> in the header?
>=20
> =20
>=20
> The =93typ=94 claim was removed as part of the JOSE change to use MIME =
type
> names for =93typ=94 and =93cty=94 header parameter values.
>=20
> Section 5.1. "typ" (Type) Header Parameter
>=20
> =20
>=20
> You write:
>=20
> "
>=20
> The typ (type) header parameter MAY be used to declare the type of this=

> JWT in an application-specific manner in contexts where this is useful
> to the application. This parameter has no effect upon the JWT
> processing. If present, it is RECOMMENDED that its value be either JWT
> or urn:ietf:params:oauth:token-type:jwt to indicate that this object is=

> a JWT.
>=20
> "
>=20
> =20
>=20
> Here again I would write: " The typ (type) header parameter is used to
> declare the type of this JWT in an application-specific manner in
> contexts where this is useful to the application."
>=20
> =20
>=20
> Why doesn't this value have any impact on the processing? It appears to=

> be useless? Would it be good to mandate that it is set to JWT or
> urn:ietf:params:oauth:token-type:jwt when the content is a JWT? Why do
> you leave two options for what the value is set to? Why would anyone us=
e
> the longer string?
>=20
> =20
>=20
> The URN value was removed as part of the JOSE change to use MIME type
> names for =93typ=94 and =93cty=94 header parameter values.
>=20
> =20
>=20
> Section 5.2. "cty" (Content Type) Header Parameter
>=20
> =20
>=20
> What is the relationship between cty and typ?
>=20
> =20
>=20
> As described in the JOSE specs that define them, =93typ=94 is the type =
of
> the entire object, whereas =93cty=94 is the type of the message contain=
ed in
> the JWS or JWE.  Both are now MIME type values.  =93cty=94 is used by J=
WTs
> in the specific way specified whereas =93typ=94 can be used as needed b=
y
> applications using JWTs.
>=20
> =20
>=20
> Section 5.3. Replicating Claims as Header Parameters
>=20
> =20
>=20
> I am not sure why you would want to have encryption of the claims and
> then again include them in cleartext. That would defeat the purpose of
> encryption. Then, you could as well just provide them in cleartext (onl=
y
> signed, for example).
>=20
> =20
>=20
> Putting the sub value into the header does not seem to be a good idea
> since this may be personal data.
>=20
> =20
>=20
> This showed up in a use case that Dick Hardt had, in which case he
> wanted to route the contents of the JWT to the recipient without being
> able to read the contents of the JWT itself.  In his case, there was an=

> intermediary handling the JWT that did not have the decryption key.
>=20
> =20
>=20
> It=92s application-specific whether the audience is private information=
 or
> not.
>=20
> =20
>=20
> Putting these fields into the header in general does not strike me as a=

> good idea since you loose the ability to sign these values. They will b=
e
> exposed to all security threats since they cannot be protected. Why not=

> use a nested JWT instead?
>=20
> =20
>=20
> They are still integrity-protected, because JWE uses only authenticated=

> encryption.  They are protected from tampering or alteration.
>=20
> =20
>=20
> The 'SHOULD' in this sentence particularly makes me nervous: "If such
> replicated Claims are present, the application receiving them SHOULD
> verify that their values are identical." This essentially means that if=

> you have protected claims and someone adds unprotected stuff into the
> header it may mean that an application would accept that. Not a good id=
ea!
>=20
> =20
>=20
> Per the above, you can=92t add stuff, because of the authenticated
> encryption used.
>=20
> =20
>=20
> Section 6 Plaintext JWTs
>=20
> =20
>=20
> Why do we want plaintext JWTs? I thought that the threat analysis
> concluded that sending this stuff of information around without any
> security protection is a bad idea.
>=20
> =20
>=20
> The JWT can either be cryptographically protected by a signature and/or=

> encryption in the JWT itself or by signature and/or encryption of a dat=
a
> structure in which the JWT is conveyed.  For instance, if it is returne=
d
> from an OAuth Token Endpoint, it is integrity protected by the channel=92=
s
> use of TLS and so may not need to be signed and/or encrypted in some
> application contexts.  OpenID Connect uses this capability in several
> places, for instance, as does Phil Hunt=92s OAuth Authentication draft.=

>=20
> =20
>=20
> Section 7. Rules for Creating and Validating a JWT
>=20
> =20
>=20
> I am curious why this section is so extensive given that we are
> essentially just applying JWS and JWE here. Wouldn't a pointer to the
> JWS/JWE spec be sufficient?
>=20
> =20
>=20
> It=92s longer because the JWT adds two things:  First, the contents can=
 be
> either a JWS or JWE, and so there=92s logic described for the slightly
> different actions taken in the two cases.  Second, the JWT can be
> nested, so the logic for nesting and detecting nested JWTs is defined. =

> It **does** just rely on JWS and JWE for the creation and verification
> aspects of the JWS and JWE aspects of JWTs.
>=20
> =20
>=20
> That said, I did remove a step that was actually a pure duplication of =
a
> corresponding JWS/JWE step.
>=20
> =20
>=20
> Ciao
>=20
> Hannes
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> _______________________________________________
>=20
> OAuth mailing list
>=20
> OAuth@ietf.org
>=20
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--PSPTctst4rODBX7iGeVHMPIPdP0NShqWG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTV3wyAAoJEGhJURNOOiAt2gQH/RaTr8TmeCyMBMMr5aPiBzrO
yQnQ3ad8I6TWhOgfgfIH0FgnLptA8K3MzixhyUTL+rRQnhIwXKB57fQxa48WRDlD
DLpQgejT7Nvq/XTHckvrxMBwD2yDINLXThrw9yB7rjbbr4Q+7VVGRTe61+m4exVk
wv2A5jrjB/996ca4FXZQbFt4+b9sLrmSdFYUAX3pIM71LE4acPE+I4czTbbLd79n
ufocID9piFJZylU2fr5d5k6ro7A4dVp8itj9EcXS2jMGekBC0ObQfV+yfHsu4QCg
gn+8r8rWbPDQqpQgrSWc0xsL7t+pJ/rdU3zbMYXgLPzMDGch4OHVcFDXhCEIZ0E=
=jeg6
-----END PGP SIGNATURE-----

--PSPTctst4rODBX7iGeVHMPIPdP0NShqWG--