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: [email protected] [mailto:[email protected]] On Behalf Of Hannes
Tschofenig
Sent: Monday, November 26, 2012 3:11 AM
To: [email protected]
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
