Signing HTTP Signatures Section 2.3 Question Concerning Lists

[aljones15]

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#name-list-prefixes

Section 2.3 states:

A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the parameter prefix with the value of N as an integer.

A list prefix value is canonicalized by applying the serialization algorithm described in Section 4.1.1 of RFC8941 [RFC8941] on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List.

RFC8941 Structured Field Values 4.1.1 contains the rules for list values.

The following are valid lists in that section:

A non-inner list:

Example-List: sugar, tea, rum

An inner list:

Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1

All examples in the Signing HTTP Signatures spec use inner lists and a non-normative section states:

This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries:

So, are we supporting non-inner lists or should we parse all lists as inner lists? Do we need to support both and somehow detect which type of list the header contains and use the prefix to get the results of the parsed structured field value? This section seems to lack normative statements for how to parse inner lists (as a dictionary entry's value or as an inner list itself?) and how to handle lists that are not inner lists if they are allowed at all. The examples imply that lists need to conform to section 4.1.1.1, but the spec itself implies that inner and non-inner lists are ok.

To further add to the confusion, the examples use an inner list which is a single list and then pull from values in that single list. This is consistent with the behavior of a list entry in a dictionary, but not with an inner list behavior from the sf spec verbatim.

One additional issue: it is not clear how to handle lists with items with params, but I'm assuming we include the params.

[jricher]

The editors are considering dropping list prefix processing, but keeping dictionary key indexing.

[aljones15]

The editors are considering dropping list prefix processing, but keeping dictionary key indexing.

That might be a good idea as lists in structured fields seem to have some complexity to them. Any responses to the other questions though? I'll try to keep up with the spec.

[jricher]

So, you parse inner lists (where they are used) as inner lists, not as dictionary values -- though the dictionary value parser can be an inner list, so that has to be one of the detected options. The structured fields spec provides deterministic parsing based on an input string, which should always be unambiguous here.

Some of the examples were a bit sloppy with the inner vs. outer list syntax, and we're going to clean that up. But I think dropping the list prefix processing directives will, for the most part, avoid most of the questions being raised here.

[jricher]

List prefixes have been dropped by #1529