IETF Logo Mail Archive

Re: [jose] Extensibility (was "Criticality")

Mike Jones <Michael.Jones@microsoft.com> Sat, 29 December 2012 01:11 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5244E21F8E46 for <jose@ietfa.amsl.com>; Fri, 28 Dec 2012 17:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD1Lxu9RSUDS for <jose@ietfa.amsl.com>; Fri, 28 Dec 2012 17:11:17 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0E18921F8E44 for <jose@ietf.org>; Fri, 28 Dec 2012 17:11:16 -0800 (PST)
Received: from BL2FFO11FD015.protection.gbl (10.173.161.204) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:11:09 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:11:08 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:11:08 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: 'Hannes Tschofenig' <hannes.tschofenig@gmx.net>, "'jose@ietf.org'" <jose@ietf.org>
Thread-Topic: [jose] Extensibility (was "Criticality")
Thread-Index: Ac3lYV4dSeIJBTB9S2ueBe/Iw5czLQ==
Date: Sat, 29 Dec 2012 01:11:07 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0ADF@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(43784002)(13464002)(50986001)(49866001)(74662001)(46406002)(56816002)(44976002)(47736001)(55846006)(33656001)(47976001)(76482001)(16406001)(54316002)(50466001)(23726001)(46102001)(4396001)(550184003)(59766001)(53806001)(31966008)(56776001)(77982001)(47446002)(51856001)(54356001)(74502001)(47776002)(5343655001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Subject: Re: [jose] Extensibility (was "Criticality")
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: Sat, 29 Dec 2012 01:11:21 -0000

The clarification below has been applied in the latest versions of the specifications.

				Thanks again,
				-- Mike

-----Original Message-----
From: Mike Jones 
Sent: Monday, December 10, 2012 6:30 PM
To: 'Hannes Tschofenig'; jose@ietf.org
Subject: RE: [jose] Extensibility (was "Criticality")

As I think you know, there's an open issue in the JOSE working group about whether all header fields must be understood or whether a mechanism should be defined to specify which header fields may be safely ignored if not understood.  John Bradley and Richard Barnes and I have been drafting a note about these choices to the JOSE working group, which I expect should go out any day now.

Per my reply to your note on the OAuth list, the intended meaning is "The use of this header parameter is OPTIONAL."  I'll plan to clarify this in the next version of the specifications.

				Thanks again,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, November 26, 2012 3:07 AM
To: jose@ietf.org
Cc: Hannes Tschofenig
Subject: [jose] Extensibility (was "Criticality")

Hi all, 

doing my shepherd writeup of some of the OAuth WG documents I was wondering how the extensibility story for these JSON-based documents should look like given a statement like this:  "Implementations MUST understand the entire contents of the header; otherwise, the JWS MUST be rejected."

Absent a "feature discovery" mechanism I am curious whether any extension is actually possible. 

(Funny enough then all individual parameters then say "This header parameter is OPTIONAL.") 

Since this type of extensibility feature does not seem to a be a new concept I am curious how it has been handled (successfully) in other specifications. 

Ciao
Hannes

PS: I remember that this has been discussed during the meeting but I do not know what the outcome of the discussion was. The meeting minutes do not seem to be available yet.  
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

v2.20.3 | Report a Bug | By Email