Response headers should use consistent separators

[sbweeden]

The Sec-Session-Registration example response header is shown with several elements, separated by semi-colons:

Sec-Session-Registration: "path";challenge=:Y2hhbGxlbmdl:;es256;rs256;authorization=:YXV0aGNvZGU=:

The Sec-Session-Challenge example response header is shown with two elements, separated by a comma:

Sec-Session-Challenge: session_identifier=<session identifier>,challenge=<base64url encoded challenge>

Can we just use a consistent separator for both response headers?

[sbweeden]

Hey @kmonsen just a quick question on the closing out of this one. In the readme here, Sec-Session-Challenge is described as (bold is mine):

a list of challenge values that may specify an optional "id" parameter: "challenge_value";id="session_id".

If this is a list, and a challenge value may be accompanied by an optional id, and the challenge and the id are separated by a semi-colon, then what are the elements of the list separated by? Said another way, what is an example of a response header which contains multiple challenge values (with optional id's)?

[kmonsen]

This is a bit convoluted because of how (at least Chrome) works with structured headers.

So lets say you have two sessions and you want to send challenges ahead of time to save a roundtrip later, that would look like this: Sec-Session-Challenge: "challenge 1";id="session 1" Sec-Session-Challenge: "challenge 2";id="session 2"

This is equivalent to: Sec-Session-Challenge: "challenge 1";id="session 1", Sec-Session-Challenge: "challenge 2";id="session 2"

and with equivalent I mean in Chromium we really cannot tell how it was in the HTTP header.

Finally, why is id="" optional. This is for a corner case where the server is not satisfied with the challenge in the registration request and wants it signed with a new challenge (maybe due to too much time passing). The session does not have an ID at this time since the server will assign it in the response to this request.

For all of these we are happy to take suggestions if it can improve clarity, this is what we thought made most sense after some exploration. We have a different syntax internally, but have committed to migrate to whatever the community things is best for the final spec.

[kmonsen]

To summarize, whenever we think it is legal to have two or more of a header, they will be in the form of list items of structured headers. This means "," can be a separator and this should not be used in other ways.

Note all headers should be converted to structured headers before we are presenting the more formal spec which we aim to do before TPAC in a few weeks.

[chen-chao]

Hey @sbweeden, with

a list of challenge values that may specify an optional "id" parameter: "challenge_value";id="session_id".

I mean

a list of challenge values that may specify an optional "id" parameter

Example: "challenge_value";id="session_id", "challenge_value2";id="session_id2". Comma is the separator used for list in RFC 8941.

Thoughts are welcome to make it clearer.

[sbweeden]

I think that a multi-challenge example alongside the single challenge example with one of the list items in the multi-challenge example including the optional id would be great.

[kmonsen]

Thanks, I updated the examples.