[jose] Namespace

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 26 November 2012 11:11 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9503121F8449 for <jose@ietfa.amsl.com>; Mon, 26 Nov 2012 03:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OBfMXOJgVrSb for <jose@ietfa.amsl.com>; Mon, 26 Nov 2012 03:11:11 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net []) by ietfa.amsl.com (Postfix) with SMTP id 5690B21F8448 for <jose@ietf.org>; Mon, 26 Nov 2012 03:11:11 -0800 (PST)
Received: (qmail invoked by alias); 26 Nov 2012 11:11:10 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO []) [] by mail.gmx.net (mp019) with SMTP; 26 Nov 2012 12:11:10 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19he49IBc1hn3zoXkeEY7fb9xeEb3dxc6oQgJXRGf ZU6WEDyE7W/Cbw
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1085)
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Date: Mon, 26 Nov 2012 13:11:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F1412B7-4585-4372-9B2F-FA852DA759A8@gmx.net>
References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net>
To: jose@ietf.org
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: [jose] Namespace
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2012 11:11:12 -0000

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?