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 protected] [mailto:[email protected]] On Behalf Of Hannes
Tschofenig
Sent: Wednesday, February 06, 2013 10:32 PM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [jose] POLL(s): header criticality
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
