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

Richard Barnes <> Wed, 06 February 2013 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E144B21F855D for <>; Wed, 6 Feb 2013 11:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.033
X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y4BINTpQm8Tk for <>; Wed, 6 Feb 2013 11:02:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::242]) by (Postfix) with ESMTP id 1411621F8556 for <>; Wed, 6 Feb 2013 11:02:18 -0800 (PST)
Received: by with SMTP id gw10so261048lab.1 for <>; Wed, 06 Feb 2013 11:02:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=bR3FLMhKXvl7BJDcMgRI4EBhuhwnvtlgI+ylTsFHb3Y=; b=PclFsSXCIgQKa6PKsMfD1viMcRdJFYaHYjHF5CdmaXtMWAmnsGk9bZcaUstzoWITXt u2HL563/neF+15jz6kzwbXMSsS8jWnOE3fLW/n3aNIEoc6qd2h22ZypxQrzaheIVVlWZ PWNX+EOIKl6SeSn+2raA9qeEPjZl0+YYjisXqF1Z/c4jHMVgk4dtRXRO3GrgEqyuNzru f7uCpJE33eJ/78WnNp9M8II33yr96Sz6eRTEog9VM6XT0xLkRjOeGgqnkXDUdThz+1Po 75VdgsivMi7ppVnjETIHy1JoD7aQtRcFrzn1ZPZZihKrTxVLbkVAJETdNWW1ZSVoenO/ A9tA==
MIME-Version: 1.0
X-Received: by with SMTP id lm20mr27392498lab.42.1360177337799; Wed, 06 Feb 2013 11:02:17 -0800 (PST)
Received: by with HTTP; Wed, 6 Feb 2013 11:02:17 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Wed, 06 Feb 2013 14:02:17 -0500
Message-ID: <>
From: Richard Barnes <>
Content-Type: multipart/alternative; boundary="f46d04374ee10d159104d512f743"
X-Gm-Message-State: ALoCoQnj/ZdPMWT+J5Ofv4/+kGpd5za/kCmYaDl+8wLfu30uEYKw914C9k9ph+293/P9sdiNku73
Subject: Re: [jose] POLL(s): header criticality
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Feb 2013 19:02:26 -0000


Further notes:

On SECOND POLL: Voting "Yes" on the SECOND POLL is equivalent to voting
"NO" on the FIRST POLL.  If the requirement isn't placed on any particular
element of the system, then nobody will implement it, and there will be no

On THIRD POLL: I don't care all that much about the specific syntax, but I
have a strong preference that these non-critical fields be excluded from
the integrity check that is applied to the header.  So I would prefer
something like what Dick suggested, but encoded as a separate element of a
JW* object.  As Breno notes, this can be done in a backwards compatible
way.  (I voted "B" because I understood "A" to imply something like Mike's
earlier proposal, which would have just had a list of field names.)

In any case, I would encourage the chairs to focus on the first poll, and
view any results in the second and third as informative for further
discussion of wording or syntax.

On Wed, Feb 6, 2013 at 1:47 PM, Nat Sakimura <> wrote:

> 2013/2/4 Karen O'Donoghue <>
>> 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
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> @_nat_en
> _______________________________________________
> jose mailing list