Subject: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

From: "jose issue tracker" <[email-masked]>
Date: Wed, 03 Apr 2013 18:13:32 -0000

#17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

 Recipients of an encrypted token sometimes are not the audience, and may
 not know who the issuer is. Allowing these values to be in the header
 enables a recipient to have a hint if the token needs to be handed to
 another party for processing, and a hint of who the issuer was. These
 values are not confirmed until validation of the token has been performed,
 but enables the appropriate parties and keys to be used to validate.

 Suggested added text:

 4.1.x The "iss" (issuer) Header Parameter

 The "iss" (issuer) header parameter identifies the principal that
 issued the JWT.  The processing of this header parameter is generally
 application specific.  The "iss" value is case sensitive.  This
 header parameter is OPTIONAL.

 4.1.x The "aud" (audience) Header Parameter

 The "aud" (audience) header parameter identifies the audience that the
 JWT is intended for.  The principal intended to process the
 JWT MUST be identified with the value of the audience header parameter.
 If
 the principal processing the header parameter does not identify itself
 with the
 identifier in the "aud" header parameter value then the JWT MUST be
 rejected.  The interpretation of the audience value is generally
 application specific.  The "aud" value is case sensitive.  This
 header parameter is OPTIONAL.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked]   |  [email-masked]
     Type:  enhancement  |     Status:  new
 Priority:  major        |  Milestone:
Component:  json-web-    |    Version:
  encryption             |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/17>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 03 Apr 2013 20:03:51 -0000

Comment (by [email-masked]):

 I believe that this is a JWT issue – not a JOSE issue.  I'd suggest that
 you re-file this issue to be considered for the JWT spec, Dick, and close
 it here, as it's JWT-specific.  The OAuth issue tracker (which can be used
 for the JWT spec, since it's in the OAuth working group) is at
 http://trac.tools.ietf.org/wg/oauth/trac/.

 I think the real change you're requesting is to have the JWT spec add the
 "iss" and "aud" claims, which it defines, to the list of reserved JWE
 header parameter values, and to say that the "iss" and "aud" claim values
 defined by the JWT spec may appear in the JWE header.  The JWT spec *can*
 reserve JOSE header fields.  (Any spec can, through use of the IANA
 registry.)  This doesn't have to be done in the JWE spec.

 A processing question you'd need to answer is whether, if present in the
 JWE header, these claim values must also appear in the JWT Claims Set with
 identical values, or whether it's your intent to allow or require them to
 appear in exactly one of the two locations.

  encryption             |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Apr 2013 20:53:08 -0700

I don't think it is a JWT issue. JWT already reserves 'aud' and 'iss' and defines them.

There is a list of reserved header parameter names in JWE, and I would like 'aud' and 'iss' to be added just like 'tip' is there. Unless the list of reserved header parameter names in JWE is moving to JWT, then it would seem REALLY confusing to an implementer to have to look in both JWT and JWE to see what the list of reserved header parameter names is. Or am I missing something? 

As to your processing question, it they are present in the JWE header and in the payload, then I would think that they must match.

-- Dick

On Apr 3, 2013, at 1:03 PM, "jose issue tracker" <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "jose issue tracker" <[email-masked]>
Date: Thu, 04 Apr 2013 03:57:10 -0000

Comment (by [email-masked]):

 I agree with Mike that these don't really belong in the core JWE/JWS
 specs.

 I would suggest we address this issue more generally, by creating an IANA
 registry of reserved parameter names, with a fairly liberal inclusion
 policy.  That registry could have a field to indicate whether JOSE
 implementations are REQUIRED to support a given parameter (MTI
 parameters).  (Note that this is different from whether a JOSE object is
 REQUIRED to contain a parameter.)  Perhaps we could have optional
 parameters under a fairly liberal policy (e.g., Specification Required),
 with a higher bar for MTI parameters (e.g., Standards Action).

 If we set up the registry in this way, then Dick could write a short
 Informational document that would register these fields.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:2>
jose <http://tools.ietf.org/jose/>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Apr 2013 21:29:23 -0700

Actually, Mike was suggesting that the issue be moved to the JWT WG. 

I'll settle with the JWE spec pointing to an IANA registry. Speaking as an implementer, if there is a list of reserved names in the spec, I'm likely to think that is all of them.

I'm a little unsettled that no one else has had any feedback on having 'aud' and 'iss' in the JWE header. Is my implementation the only that has that requirement? 

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2013 16:27:42 +0000

JWT defines "aud" and "iss" and reserves them as claim names but not as JWE header parameter names, nor does it currently specify their usage in that location.  My point is that I think the best way to accomplish what you're asking for is to have the JWT spec also reserve these as JWE header parameter names and define the semantics and processing rules associated with using them in that location.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Wednesday, April 03, 2013 8:53 PM
To: jose issue tracker
Cc: [email-masked]; Mike Jones; [email-masked]
Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

-- Dick

On Apr 3, 2013, at 1:03 PM, "jose issue tracker" <[email-masked]> wrote:

> I believe that this is a JWT issue - not a JOSE issue.  I'd suggest 
> that you re-file this issue to be considered for the JWT spec, Dick, 
> and close it here, as it's JWT-specific.  The OAuth issue tracker 
> (which can be used for the JWT spec, since it's in the OAuth working 
> group) is at http://trac.tools.ietf.org/wg/oauth/trac/.
> 
> I think the real change you're requesting is to have the JWT spec add 
> the "iss" and "aud" claims, which it defines, to the list of reserved 
> JWE header parameter values, and to say that the "iss" and "aud" claim 
> values defined by the JWT spec may appear in the JWE header.  The JWT 
> spec *can* reserve JOSE header fields.  (Any spec can, through use of 
> the IANA
> A processing question you'd need to answer is whether, if present in 
> the JWE header, these claim values must also appear in the JWT Claims 
> Set with identical values, or whether it's your intent to allow or 
> require them to appear in exactly one of the two locations.
> 
> --
> -------------------------+--------------------------------------------
> -------------------------+-----
> -------------------------+--------------------------------------------
> -------------------------+-----
> 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:1>

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2013 16:32:49 +0000

Responding to your "unsettled" remark, I suspect most people are fine with having the "aud" and "iss" be claims in the JWT where they normally are.  Yes, you have to decrypt the token to get these claim values, but if you're going to use the token, you'll have to do that anyway.

I don't think it's clear to most people what problem is being solved by potentially these fields to be present in a different location.  Without a compelling use case, this just seems like more to implement without a clear benefit of doing so.

				-- Mike

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 9:29 PM
To: jose issue tracker
Cc: [email-masked]; Mike Jones; [email-masked]; [email-masked]
Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

-- Dick

On Apr 3, 2013, at 8:57 PM, "jose issue tracker" <[email-masked]> wrote:

> I would suggest we address this issue more generally, by creating an 
> IANA registry of reserved parameter names, with a fairly liberal 
> inclusion policy.  That registry could have a field to indicate 
> whether JOSE implementations are REQUIRED to support a given parameter 
> (MTI parameters).  (Note that this is different from whether a JOSE 
> object is REQUIRED to contain a parameter.)  Perhaps we could have 
> optional parameters under a fairly liberal policy (e.g., Specification 
> Required), with a higher bar for MTI parameters (e.g., Standards Action).
> 
> <http://trac.tools.ietf.org/wg/jose/trac/ticket/17#comment:2>

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Apr 2013 15:52:15 -0300

I am not against having them as JWE header elements, I have raised the point in several discussions.

However given that the decryption key is generally already in the hands of the RP it is hard to make the argument that a kid, thumbprint or jwk object are not enough for the recipient to identify what decryption key to use.

I can see a use in a case like Matt Millers XMPP encryption example where the sender doesn't know the public key of the recipient only its name in that case the recipient won't have the decryption key and needs to know in the unencrypted part of the message who to go and ask for the key.

I think in the XMPP case the recipient sends its public key and the received "kid" back to the issuer and asks for the decryption key to be encrypted by its public key and sent back.   This is perhaps the sort of thing where having the iss in the unencrypted envelope is a requirement.

"aud" is also arguably useful if you have a multi hop situation where the client needs to make a forwarding decision without creating yet another level of wrapping for the token.

So I do see uses for them.  

I do agree with Mike that it may be best to use the definitions in JWT and have the processing rule about what happens if you get the claim in the header and in the body or if it is only in the header laid out there.   

The thing that is important in a JWE context is if those claims are going to be integrity protected.   There is continued debate about removing the envelope from the integrity protection.  That is a JWE issue.   I also think if they are in JWT as being allowed in the JWE header referencing that from JWE is not a bad thing. 

John B.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Apr 2013 13:09:58 -0700

> JWT defines "aud" and "iss" and reserves them as claim names but not as JWE header parameter names, nor does it currently specify their usage in that location.  My point is that I think the best wa…

Repeating that you think it is "best" is not educating me on *why* you think it is "best"!

The other reserved JWE header parameter names are not reserved in JWT. The current list of reserved JWE header parameter names are in the JWE document. Having another place to look for what names are reserved looks inefficient and error prone unless ALL reserved JWE header parameter names are listed in JWT.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Apr 2013 13:14:15 -0700

> However given that the decryption key is generally already in the hands of the RP it is hard to make the argument that a kid, thumbprint or jwk object are not enough for the recipient to identify w…

See my example

> "aud" is also arguably useful if you have a multi hop situation where the client needs to make a forwarding decision without creating yet another level of wrapping for the token.

I have potential multi hop that requires "aud"

> The thing that is important in a JWE context is if those claims are going to be integrity protected.   There is continued debate about removing the envelope from the integrity protection.  That is…

I would think it would make sense to have one list of reserved JWE header parameters, not two. Of course, additional ones may be defined in an IANA registry.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Apr 2013 13:42:25 -0700

> I don't think it's clear to most people what problem is being solved by potentially these fields to be present in a different location.  Without a compelling use case, this just seems like more to…

I will see if I can explain the use case better.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and decrypt tokens from them. 

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who sent the token, is to look at the KID as the "iss" claim is encrypted. If the "kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the associated symmetric key, and then decrypt and verify the token and THEN see who sent it. If there is a collision in KID values (Bon and Charlie gave the same KID for different keys), then Alice will not know which symmetric key to use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symmetric key to Gwen. 

Ellen and Gwen trust each other and know how to talk to each other. Gwen does not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for knowing that Ellen can do that. The "aud" property would allow Gwen to give the token to Ellen to decrypt and verify.

Feel free to ask for clarifications.

This is what is happening in A2P3 that enables a distributed system.

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2013 23:03:35 +0000

I think it's better for three reasons.  First, I think it's better to reserve the names and define the new processing rules in the document where they're defined - the JWT spec.

Second, the "iss" and "aud" header values aren't meaningful in JWEs in the general case - only in JWEs whose message is a JWT Claims Set.  That's a scoping argument that they shouldn't be defined in the JWE spec.

Third, as is normal for IETF specs, the "one place to look for reserved JWE header names" is the IANA registry for those names.  Yes, the JWE spec reserves an initial set of names, but it won't be the only spec to reserve header parameter names, and so to see the full list, developers have to consult the registry.

				-- Mike

P.S.  There's already an example of the JWT spec reserving names in a registry defined by the JWS spec.  See http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.3.1.  Reserving header parameter names in the JSON Web Signature and Encryption Header Parameters Registry established in JWS (see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-7.1.1) would be done in an analogous manner.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Apr 2013 16:28:37 -0700

> I think it's better for three reasons.  First, I think it's better to reserve the names and define the new processing rules in the document where they're defined - the JWT spec.

Um, so why are the other header parameter names in JWT? I'm arguing for consistency.

> Second, the "iss" and "aud" header values aren't meaningful in JWEs in the general case - only in JWEs whose message is a JWT Claims Set.  That's a scoping argument that they shouldn't be defined i…

When I look at it as an implementer, the "iss" and "aud" are used to make a decision in how to process (decrypt) the message and are just as useful as the "kid" or any of the other crypto fields that are in the header.

> Third, as is normal for IETF specs, the "one place to look for reserved JWE header names" is the IANA registry for those names.  Yes, the JWE spec reserves an initial set of names, but it won't be…

Sure. When was the last time you looked at the registry? I've looked once to see all the URI schemes.
I understand that is the "official" list, but many people will view the list in the spec as the list unless there are lots of other ones in the registry. I'm speaking practically as to what happens.

> P.S.  There's already an example of the JWT spec reserving names in a registry defined by the JWS spec.  See http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.3.1.  Reserving…

So why don't we put ALL the reserved header names there so that we are consistent?

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 16:41:20 -0700

Mike,

I want to make sure that I understand how the registry is going to work.
After I get an answer I will go back and review the document to make sure
that it is both clear and consistent with your response.

It is clear that any document (not just an IETF document) can create a new
entry in the header registry.  Once this has been done there are two
possible results:

1.  The resulting registration is for a specific protocol - thus if the JWT
document registers iss and aud they would be specific for to the JWT
documents or
2.  The resulting registration is permitted for any protocol - thus the JWT
document would be required to provide clear documentation about how the iss
and aud header fields would operate for any potential new protocol that
wanted to use these header fields.

I think that both you and the WG believe that the second statement is
correct.  This is just a verification for me personally.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Thursday, April 04, 2013 4:04 PM
> To: Dick Hardt
> Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header
Parameter
> Names
> 
> I think it's better for three reasons.  First, I think it's better to
reserve the
> names and define the new processing rules in the document where they're
> defined - the JWT spec.
> 
> Second, the "iss" and "aud" header values aren't meaningful in JWEs in the
> general case - only in JWEs whose message is a JWT Claims Set.  That's a
> scoping argument that they shouldn't be defined in the JWE spec.
> 
> Third, as is normal for IETF specs, the "one place to look for reserved
JWE
> header names" is the IANA registry for those names.  Yes, the JWE spec
> reserves an initial set of names, but it won't be the only spec to reserve
> header parameter names, and so to see the full list, developers have to
> consult the registry.
> 
> 				-- Mike
> 
> P.S.  There's already an example of the JWT spec reserving names in a
registry
> defined by the JWS spec.  See
http://tools.ietf.org/html/draft-ietf-oauth-json-
> web-token-06#section-9.3.1.  Reserving header parameter names in the JSON
> Web Signature and Encryption Header Parameters Registry established in JWS
> (see
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-
> 7.1.1) would be done in an analogous manner.
> 
> Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header
Parameter
> Names
> > JWT defines "aud" and "iss" and reserves them as claim names but not as
> JWE header parameter names, nor does it currently specify their usage in
that
> location.  My point is that I think the best way to accomplish what you're
> asking for is to have the JWT spec also reserve these as JWE header
> parameter names and define the semantics and processing rules associated
> with using them in that location.
> 
> Repeating that you think it is "best" is not educating me on *why* you
think it
> is "best"!
> 
> The other reserved JWE header parameter names are not reserved in JWT.
> The current list of reserved JWE header parameter names are in the JWE
> document. Having another place to look for what names are reserved looks
> inefficient and error prone unless ALL reserved JWE header parameter
> names are listed in JWT.
> 
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 00:06:36 +0000

Yes, I believe that the intent is 2 - these are global registrations.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, April 04, 2013 4:41 PM
To: Mike Jones; 'Dick Hardt'
Cc: [email-masked]; [email-masked]
Subject: RE: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

Mike,

I want to make sure that I understand how the registry is going to work.
After I get an answer I will go back and review the document to make sure that it is both clear and consistent with your response.

It is clear that any document (not just an IETF document) can create a new entry in the header registry.  Once this has been done there are two possible results:

1.  The resulting registration is for a specific protocol - thus if the JWT document registers iss and aud they would be specific for to the JWT documents or 2.  The resulting registration is permitted for any protocol - thus the JWT document would be required to provide clear documentation about how the iss and aud header fields would operate for any potential new protocol that wanted to use these header fields.

I think that both you and the WG believe that the second statement is correct.  This is just a verification for me personally.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mike Jones
Parameter
reserve the
> names and define the new processing rules in the document where 
> they're defined - the JWT spec.
> 
> Second, the "iss" and "aud" header values aren't meaningful in JWEs in 
> the general case - only in JWEs whose message is a JWT Claims Set.  
> That's a scoping argument that they shouldn't be defined in the JWE spec.
> 
JWE
> reserves an initial set of names, but it won't be the only spec to 
> reserve header parameter names, and so to see the full list, 
> developers have to consult the registry.
> 
> 				-- Mike
> 
registry
> web-token-06#section-9.3.1.  Reserving header parameter names in the 
> JSON Web Signature and Encryption Header Parameters Registry 
> established in JWS (see
Parameter
that
> location.  My point is that I think the best way to accomplish what 
> you're asking for is to have the JWT spec also reserve these as JWE 
> header parameter names and define the semantics and processing rules 
> associated with using them in that location.
> 
think it
> document. Having another place to look for what names are reserved 
> looks inefficient and error prone unless ALL reserved JWE header 
> parameter names are listed in JWT.
> 
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 8 Apr 2013 17:46:13 +0000

To be clear in XMPP, the sender doesn't know the public key of the recipient(s), but does know the address (not name).  XMPP addresses have very specific semantics (RFC 6122), to the point where aliasing has proven to be practically impossible to do.  At the same time, I don't want to be concerned with JOSE-level mismatches because of the addressing semantics.

In my opinion, including "iss" and/or "aud" in JWE doesn't buy XMPP anything, but does introduce a new failure point.  I don't think it's reasonable to expect an XMPP application to store all keys globally.  At most, I expect the key relevant to the user's login would be globally available, but all session keys would be isolated from each other; "kid" should be enough to resolve the proper key.

I'd rather not add something to JWE/JWS unless there's a broader need.  So far I've only seen mention of JWT use cases that need this, and my own which I'm currently not in favor of including.

Personally, I think the pending changes on JWE/JWS/JWK header criticality, as well as a decent registry of parameters (which is defined in JWE, but might need some further definition) means JWT can add these header parameters without impacting all JOSE-using applications.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.