Re: [jose] Namespace

[Mike Jones <[e-mail]>]

I've repeated my reply to your Namespace comment on the OAuth list below.  My comments are in green.



                                                                Thanks again,

                                                                -- Mike



- 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.



If people are following the spec and using (IANA) reserved claim names, or public claim names (those containing a collision-resistant namespace), then the same names will always have the same semantics.  IANA is used for reserved claim names, where conflicts would otherwise be likely.  IANA is unnecessary for public claim names, because the collision-resistant namespace in the claim name prevents duplication.



Do we really need to support claims where uniqueness cannot be guaranteed?



Private claim names are there because in some contexts, the communication is between a fixed or constrained set of parties between whom private agreements are a perfectly acceptable namespace allocation solution.  Indeed, it wouldn't make much sense to register the meanings of claims with IANA that will only be used in a closed environment.



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?



The same namespace allocation strategy is being used by JOSE.



Btw, is it allowed to use JavaScript reserved keywords as claim names?



Yes



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
Sent: Monday, November 26, 2012 3:11 AM
To: [e-mail]
Cc: Hannes Tschofenig
Subject: [jose] Namespace



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







_______________________________________________

jose mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/jose