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

From: Karen O'Donoghue <[email-masked]>
Date: Mon, 04 Feb 2013 09:48:34 -0500

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.)

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 6 Feb 2013 13:31:08 +0000

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Monday, February 4, 2013 6:49 AM
To: [email-masked]
Subject: [jose] POLL(s): header criticality

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
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Wed, 6 Feb 2013 06:40:48 -0700

FIRST POLL:  NO
SECOND POLL:  YES
THIRD POLL:  A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Monday, February 4, 2013 6:49 AM
To: [email-masked]
Subject: [jose] POLL(s): header criticality

Folks,

Thanks,
Karen

*******************

********************

************************

On 2013-02-04, at 7:48 AM, Karen O'Donoghue <[email-masked]> wrote:

> 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.
> 
> 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.
> 
> _______________________________________________
> jose mailing list
> [email-masked]

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 6 Feb 2013 15:27:38 +0000

> FIRST POLL: Should all header fields be critical for implementations to understand?

NO

> SECOND POLL: Should the result of the first poll be "YES", should text like the following be added? 

YES

> 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

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Feb 2013 15:27:48 +0000

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Monday, February 04, 2013 6:49 AM
To: [email-masked]
Subject: [jose] POLL(s): header criticality

Folks,

Thanks,
Karen

*******************

********************

************************

---

From: Dick Hardt <[email-masked]>
Date: Wed, 6 Feb 2013 09:03:12 -0800

FIRST POLL: Yes

SECOND POLL: YES

THIRD POLL: B

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 6 Feb 2013 09:11:49 -0800

FIRST POLL: Yes

SECOND POLL: YES

THIRD POLL: B

-- 
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 6 Feb 2013 09:24:09 -0800

Clarification:

I only support THIRD POLL: B if the new header can be omitted, so that
3-component JWTs are still valid. I don't support this option if
backwards-incompatible.

-- 
--Breno

---

From: George Fletcher <[email-masked]>
Date: Wed, 06 Feb 2013 12:33:12 -0500

FIRST POLL:  NO
SECOND POLL:  YES
THIRD POLL:  A

On 2/4/13 9:48 AM, Karen O'Donoghue wrote:
> 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.
>
> the following polls have been created. Please respond before 11 
> February 2013.
>
> Thanks,
> Karen
>
> *******************
> 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.
>
> B – Introduce a second header, where implementations must understand 
> all fields in the first but they may ignore not-understood fields in 
> the second.
>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 6 Feb 2013 09:40:33 -0800

I misunderstood the Third Poll options.

I was thinking that all properties to be ignored would be a property of the header object. ie. all ignorable properties are sub property of a "ignorable" property.

eg. all "ign" properties can be ignored

{ "alg": "ES256"
, "ign": 
	{  "notes":"this property can be ignored" }
}

So I am voting C for the third poll, a different option.

btw: I continue to be surprised that we are using JSON and only doing name/value pairs.

-- Dick

---

From: Edmund Jay <[email-masked]>
Date: Wed, 6 Feb 2013 09:51:42 -0800 (PST)

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

________________________________
From: Karen O'Donoghue <[email-masked]>
To: [email-masked]
Sent: Mon, February 4, 2013 6:48:35 AM
Subject: [jose] POLL(s): header criticality

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

*******************

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.

************************
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.

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Feb 2013 17:59:42 +0000

For what it's worth, I believe that Dick's proposed syntax, where the may-be-ignored-if-not-understood header fields are in JSON object under a specific member of the header, is compatible with the intent of the wording of "A - Define a header field that explicitly lists the fields that may be safely ignored if not understood".  He's proposing to actually put the values of those additional header fields under a defined header field, rather than using a syntax like this one:

    {"alg":"ES256",
     "ign":["notes"],
     "notes":" this property can be ignored"
    }

He's right that it's cleaner JSON.  The counter-argument is that then some header fields are in the top-level JSON object and some are not, which is an asymmetry.  I could personally live with either syntax for ignorable header fields.  A working group discussion on which syntax people prefer seems like it would be useful.

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Wednesday, February 06, 2013 9:41 AM
To: [email-masked]; [email-masked]
Subject: Re: [jose] POLL(s): header criticality

{ "alg": "ES256"
, "ign": 
	{  "notes":"this property can be ignored" } }

-- Dick

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Feb 2013 11:45:33 -0700

FIRST POLL:  NO
SECOND POLL:  YES
THIRD POLL:  A

On Mon, Feb 4, 2013 at 7:48 AM, Karen O'Donoghue <[email-masked]> wrote:

> implementations must understand all JOSE header fields)). We need to come
> to closure on this issue in order to progress the specifications.
>
> 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.”
>
> would you prefer for designating the header fields that may be ignored if
> not understood?
>
> ______________________________**_________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 6 Feb 2013 11:47:47 -0700

FIRST POLL:  NO
SECOND POLL:  YES
THIRD POLL:  A

2013/2/4 Karen O'Donoghue <[email-masked]>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Feb 2013 14:02:17 -0500

tl;dr:
FIRST POLL:   NO
SECOND POLL:  NO
THIRD POLL:   B

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
control.

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.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Feb 2013 11:08:44 -0800

1. NO
2. NO
3, B

-Ekr

---

From: Peter Yee <[email-masked]>
Date: Wed, 06 Feb 2013 12:11:09 -0800

FIRST POLL: NO
SECOND POLL:  NO
THIRD POLL:  A

---

From: <[email-masked]>
Date: Wed, 6 Feb 2013 21:16:29 +0100

YES
YES
A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Monday, February 04, 2013 3:49 PM
To: [email-masked]
Subject: [jose] POLL(s): header criticality

Folks,

Thanks,
Karen

*******************

********************

************************

---

From: hideki nara <[email-masked]>
Date: Thu, 7 Feb 2013 11:07:54 +0900

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

---
hideki nara

2013/2/4 Karen O'Donoghue <[email-masked]>:
> 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.
>
> 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.”
>
> 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?
>

---

From: Ryo Ito <[email-masked]>
Date: Thu, 7 Feb 2013 11:44:19 +0900

FIRST POLL: NO
SECOND POLL: YES
THIRD POLL: A

-- 
====================
Ryo Ito
Email : [email-masked]
====================

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 07 Feb 2013 08:32:09 +0200

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

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 7 Feb 2013 08:04:28 +0100

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

> the following polls have been created. Please respond before 11 February 

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS) 
Umeå University 
SE-901 87 Umeå, Sweden	
Phone +46 90 786 68 44
Mobile +46 70 696 68 44 
www.its.umu.se

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Feb 2013 07:20:32 +0000

Hi Hannes,

One tried-and-true method of enabling extensions is through discovery and/or negotiation.  (This fits into your (b) - there is another higher layer specification that says what is required.)  For instance, if two parties come to understand through discovery that both support an extension, then they are free to use it between themselves.

For instance, yes, in OpenID Connect, implementations can discover what algorithms and other features are supported and then use only those that are implemented by both communicating parties.  I can't imagine that this is the only JOSE use case that will employ discovery and/or negotiation.

When discovery and/or negotiation is used, implementations don't have to ignore not-understood features, because none would be used in the first place.

				Best wishes,
				-- Mike

P.S.  Yes, you're right that (a) - out-of-band agreement - could be used in some cases too.  For instance, OAuth deployments almost all employ out-of-band agreements.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 06, 2013 10:32 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] POLL(s): header criticality

Hi Karen,

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:

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.

Ciao
Hannes

On 02/04/2013 04:48 PM, Karen O'Donoghue wrote:
> need to come to closure on this issue in order to progress the specifications.
>
> YES - All header fields must continue to be understood by 
> like the following be added? "Implementation Note: The requirement to 
> - not on any particular level of library software. For instance, a 
> 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.
>
> B - Introduce a second header, where implementations must understand

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 07 Feb 2013 09:36:01 +0100

FIRST POLL: YES
SECOND POLL: YES
THIRD POLL: A

Charles Marais.

Le 07/02/2013 03:07, hideki nara a
écrit :

FIRST POLL: YES
SECOND POLL: YES
THIRD POLL: A

---
hideki nara

Folks,

Thanks,
Karen

*******************

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.

********************

************************

--

MARAIS Charles

FT/OLNC/OLPS/ASE/IDEA/UED

Tel : 02.96.05.24.18

[email-masked]

WF004Bis / R&D Lannion / 2, avenue Pierre Marzin / 22307
LANNION Cedex - France

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 07 Feb 2013 09:50:54 +0100

Hi Mike, 

whatever story the group comes up with I believe it would be important to describe this in the document since other specifications have followed a different approach. 

Knowing you guys I had already expected that you try to solve this extensibility issue using additional OpenID Connect specifications. 

I am wondering what approach other specifications have used in the past. My understanding is that XML, CMS, and PSKC follow a model where the mandatory to implement functionality is defined in the specification and additional specifications indicate what additional extensions have to be used. Is my understanding correct? 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 7 Feb 2013 07:20:32 +0000
> Von: Mike Jones <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Betreff: RE: [jose] POLL(s): header criticality

> Hi Hannes,
> 
> One tried-and-true method of enabling extensions is through discovery
> and/or negotiation.  (This fits into your (b) - there is another higher layer
> specification that says what is required.)  For instance, if two parties
> come to understand through discovery that both support an extension, then they
> are free to use it between themselves.
> 
> For instance, yes, in OpenID Connect, implementations can discover what
> algorithms and other features are supported and then use only those that are
> implemented by both communicating parties.  I can't imagine that this is
> the only JOSE use case that will employ discovery and/or negotiation.
> 
> When discovery and/or negotiation is used, implementations don't have to
> ignore not-understood features, because none would be used in the first
> place.
> 
> 				Best wishes,
> 				-- Mike
> 
> P.S.  Yes, you're right that (a) - out-of-band agreement - could be used
> in some cases too.  For instance, OAuth deployments almost all employ
> out-of-band agreements.
> 
> 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.
> 
> 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.
> 
> raising wrong expectations of the level of interoperability this work provides.
>

---

From: Casper Biering <[email-masked]>
Date: Thu, 07 Feb 2013 11:36:41 +0100

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

-- 
-- Casper

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 7 Feb 2013 22:04:18 +1100

1. NO

2. NO

3. C -- one critical field; the definition of each value for this field implies what else you need to understand; if you want to add a new field that MUST be understood, just use a new value for the one critical field.

I second Richard's comment about YES to 2.

What would a JOSE library API look like if all fields MUST be understood by “the system”? Does the “top” layer tell the library what it understands; does the library return a list of unrecognized fields?

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, 7 February 2013 6:02 AM
To: [email-masked]; [email-masked]
Subject: Re: [jose] POLL(s): header criticality

tl;dr:
FIRST POLL:   NO
SECOND POLL:  NO
THIRD POLL:   B

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 control.

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 <[email-masked]<mailto:[email-masked]>> wrote:
FIRST POLL:  NO
SECOND POLL:  YES
THIRD POLL:  A

2013/2/4 Karen O'Donoghue <[email-masked]<mailto:[email-masked]>>
Folks,

Thanks,
Karen

*******************

********************

************************

C - Other??? (Please specify in detail.)
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Stephen Kent <[email-masked]>
Date: Thu, 07 Feb 2013 11:11:41 -0500

Hannes,

I share your concern. If JOSE is to be used more widely than in the 
OpenID context, then it
probably is not a good idea to rely on constructs/conventions from that 
context re extensions.

Steve

---

From: Dirkjan Ochtman <[email-masked]>
Date: Thu, 7 Feb 2013 21:26:11 +0100

I'll second James' vote:

1. NO
2. NO
3. C -- one critical field; the definition of each value for this
field implies what else you need to understand; if you want to add a
new field that MUST be understood, just use a new value for the one
critical field.

Cheers,

Dirkjan

On Thu, Feb 7, 2013 at 12:04 PM, Manger, James H
<[email-masked]> wrote:
> 1. NO
>
> 2. NO
>
> 3. C -- one critical field; the definition of each value for this field
> implies what else you need to understand; if you want to add a new field
> that MUST be understood, just use a new value for the one critical field.
>
>
>
>
>
> What would a JOSE library API look like if all fields MUST be understood by
> “the system”? Does the “top” layer tell the library what it understands;
> does the library return a list of unrecognized fields?
>
>
>
> --
>
> James Manger
>
>
>
> 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
> 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.)
>

---

From: nov matake <[email-masked]>
Date: Sat, 9 Feb 2013 00:56:03 +0900

FIRST POLL: YES, but only for top level keys.
SECOND POLL: YES
THIRD POLL: C, +1 for defining a ignorable parameters container key as Dick proposed.

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 08 Feb 2013 16:07:45 -0500

FIRST POLL : Yes

- cause JOSE headers are security artifacts; when present, they must not 
be ignored by a processor of JOSE objects

SECOND POLL: Yes

- the language here is a bit confusing, i think the distinction sought 
here is between a deployment instance versus a static component 
(library). If I understand the intent here,
the suggestion is that a deployment instance of a JOSE processor should 
treat JOSE-defined headers as critical.

THIRD POLL: C

- high-level list of ignorable headers (vs. adding annotation to each 
header)

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Fri, 8 Feb 2013 17:43:12 -0500

Yes
Yes
No strong opinion

-----Original Message-----
From: Prateek Mishra [mailto:[email-masked]]
Sent: Friday, February 08, 2013 4:08 PM
To: [email-masked]
Subject: Re: [jose] POLL(s): header criticality

FIRST POLL : Yes

- cause JOSE headers are security artifacts; when present, they must not be 
ignored by a processor of JOSE objects

SECOND POLL: Yes

- the language here is a bit confusing, i think the distinction sought here is 
between a deployment instance versus a static component (library). If I 
understand the intent here, the suggestion is that a deployment instance of a 
JOSE processor should treat JOSE-defined headers as critical.

THIRD POLL: C

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 8 Feb 2013 14:49:01 -0800

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

- cmort

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Feb 2013 19:43:16 +0100

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  no opinion

---

From: Russ Housley <[email-masked]>
Date: Sun, 10 Feb 2013 18:01:37 -0500

FIRST POLL:   NO
SECOND POLL:  NO
THIRD POLL:   C

First, when designing CMS we discussed this field criticality topic to death.  I'm sad that we are exploring the same ratholes in even greater detail yet again.

If an implementation supports key agreement, then it needs to understand all of the key agreement headers, but it might ignore fields associated with other recipient that are using other key management approaches.

If an implementation supports key transport, then it needs to understand all of the key transport headers, but it might ignore fields associated with other recipient that are using other key management approaches.

If an implementation supports password-based encryption then it needs to understand all of thepassword-based encryption headers, but it might ignore fields associated with other recipient that are using other key management approaches.

And so on.

Russ

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Tue, 12 Feb 2013 11:13:03 +0900

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

-- 
HAYASHI, Tatsuya
Lepidum Co. Ltd.

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.