Subject: [jose] Namespace

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2012 13:11:08 +0200

Hi all, 

I posted a review of the JWT document to the OAuth mailing list but one specific issue is probably more relevant for JOSE than for OAuth.

The namespace concept form the JOSE header parameters has been copied to the "body" for the OAuth JWT spec:

Begin forwarded message:

> - Namespace
> 
> The document defines a couple of claims. Quite naturally one wants to provide extension points since others will quite likely come up with new claims in the near future. The obvious approach would be to use an IANA registry to maintain uniqueness of the labels but without using a namespace declaration concept like XML does. 
> 
> For some reason that does not seem to be enough to use IANA alone: the document introduces three types of claims, namely Reserved Claim Names, Public Claim Names, and Private Claim Names
> 
> No mechanism is stated how these claims can be differentiated but essentially everything is allowed. Section 2 ("Terminology") says that the claims that are not registered through IANA may be Domain Names, Object Identifiers (OIDs), UUIDs, etc. 
> 
> Later in Section 4.2 it is said that public claims could be a URI, which is again different to what is said in Section 2. 
> 
> Furthermore, Private Claims (as defined in Section 4.3) do not seem to have the requirement for uniqueness anymore even though Section 4 says that claim names in a JWT have to be unique. 
> 
> The danger is obviously that two parties define claim names that have different semantic. This will lead to confusion. When claims with the same names are added to a JWT then, per specification, the receiver will have to fail. 
> 
> Do we really need to support claims where uniqueness cannot be guaranteed?
> Can we decide on a few namespace concepts rather than leaving the list open-ended? What are the JOSE guys going to do about this issue?
> 
> Btw, is it allowed to use JavaScript reserved keywords as claim names?
> 

In a summary, has someone looked at the way how the header parameters are reserved? Does this make sense to you?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2012 13:15:50 +0200

Hi all, 

In Appendix A.1 of the JWS document there is an example with an HMAC SHA-256 keyed message digest.

I would have assumed that the header contains the key id so that the receipient can actually verify it.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Nov 2012 06:01:02 +0000

It may contain the key ID, or like many things OAuth, it may know which key to use by other means.  For instance, it may be supplied via dynamic registration.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, November 26, 2012 3:16 AM
To: [email-masked]
Cc: Hannes Tschofenig
Subject: [jose] Key Identifier

Hi all, 

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2012 09:00:12 +0200

Hi Mike, 

Thanks for the response.

If you indeed think that all header parameters can be configured out of band
(or guessed) then it would be good to state that assumption in the example.

For real-world practicability purposes I would assume that the key
identifier is present (regardless whether the keying material is statically
or dynamically provisioned). Somehow the right key has to be selected and
you want to make it robust (particularly when keys can be cached and
multiple keys may be used at the same time, for example, for key roll-over).

Ciao
Hannes

On 11/28/12 8:01 AM, "Mike Jones" <[email-masked]> wrote:

> It may contain the key ID, or like many things OAuth, it may know which key to
> use by other means.  For instance, it may be supplied via dynamic
> registration.
> 
> -- Mike
>