Re: [jose] POLL(s): header criticality

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 07 February 2013 06:32 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 783FB21F8447 for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 22:32:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level:
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 90tZyWDOsrrg for <jose@ietfa.amsl.com>; Wed, 6 Feb 2013 22:32:14 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7197D21F8684 for <jose@ietf.org>; Wed, 6 Feb 2013 22:32:14 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWMYG-1UQxTr30R8-00XZcQ for <jose@ietf.org>; Thu, 07 Feb 2013 07:32:13 +0100
Received: (qmail invoked by alias); 07 Feb 2013 06:32:13 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp010) with SMTP; 07 Feb 2013 07:32:13 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+IFyoz8NKI+87XOJUC2WpEMnbbu4Fs6OPoOiaZE1 XdtZLeBjJvDZBC
Message-ID: <51134A69.5020704@gmx.net>
Date: Thu, 07 Feb 2013 08:32:09 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: odonoghue@isoc.org
References: <510FCA42.5000704@isoc.org>
In-Reply-To: <510FCA42.5000704@isoc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: hannes.tschofenig@gmx.net, jose@ietf.org
Subject: Re: [jose] POLL(s): header 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: Thu, 07 Feb 2013 06:32:15 -0000

Hi Karen,

thanks for running this poll.

My problem with answering your questions is the following:

The question you are raising deals with how you want to handle 
extensions. While it is easy to say that all the features in 
specification X must be implemented it is not even clear which 
specifications you are actually referring to with question #1.

So, I am wondering how you plan to handle any extension when someone 
answers question #1 with YES. I see only the following ways:

a) there is an out-of-band agreement (for a specific system, such a 
federation) that defines what values need to be present, or

b) there is another higher layer specification that says what is required.

I assume that many of the OAuth folks have answered the question with 
YES since they are thinking that they will just write that specification 
as part of OpenID Connect.

If that's the plan I think it should be clearly articulated to avoid 
raising wrong expectations of the level of interoperability this work 
provides.

If there is a different plan then please let me know.

Ciao
Hannes


On 02/04/2013 04:48 PM, Karen O'Donoghue wrote:
> Folks,
>
> I am wrestling with how to help drive consensus on the topic of
> criticality of headers. For background, please review the current
> specification text, the minutes to the Atlanta meeting (IETF85), and the
> mailing list (especially the discussion in December with (Subj: Whether
> implementations must understand all JOSE header fields)). We need to
> come to closure on this issue in order to progress the specifications.
>
> As a tool to gather further information on determining a way forward,
> the following polls have been created. Please respond before 11 February
> 2013.
>
> Thanks,
> Karen
>
> *******************
> FIRST POLL: Should all header fields be critical for implementations to
> understand?
>
> YES – All header fields must continue to be understood by
> implementations or the input must be rejected.
>
> NO – A means of listing that specific header fields may be safely
> ignored should be defined.
>
> ********************
> SECOND POLL: Should the result of the first poll be "YES", should text
> like the following be added? “Implementation Note: The requirement to
> understand all header fields is a requirement on the system as a whole –
> not on any particular level of library software. For instance, a JOSE
> library could process the headers that it understands and then leave the
> processing of the rest of them up to the application. For those headers
> that the JOSE library didn’t understand, the responsibility for
> fulfilling the ‘MUST understand’ requirement for the remaining headers
> would then fall to the application.”
>
> YES – Add the text clarifying that the “MUST understand” requirement is
> a requirement on the system as a whole – not specifically on JOSE
> libraries.
>
> NO – Don’t add the clarifying text.
>
> ************************
> THIRD POLL: Should the result of the first poll be "NO", which syntax
> would you prefer for designating the header fields that may be ignored
> if not understood?
>
> A – Define a header field that explicitly lists the fields that may be
> safely ignored if not understood.
>
> B – Introduce a second header, where implementations must understand all
> fields in the first but they may ignore not-understood fields in the
> second.
>
> C - Other??? (Please specify in detail.)
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose