The RFC7235 syntax forWWW-Authenticate and Authorization uses , (commas) to separate key-value pairs rather that semicolons as many other header fields and as suggested by RFC8941 for new header fields. This means that one has to be very careful when parsing concatenated WWW-Authenticate or Authorization headers. This was discussed in Clarify multiple authorization header behaviour or concatenation method issue on the http-core repo in Nov 2018. I am not 100% sure what the result of that discussion was.
We have potentially a few Authentication methods we would like to allow. At least: Basic, Bearer (for Solid-OIDC I guess, but the spec does not make that clear), and HttpSig (that name is not settled as it could also be Signature as it was used to be with draft-cavage) for HttpSig Authentication.
We need to make sure they play well together. Is this problem overcome with HTTP/2.0? One could also use new authentication headers that don't come with the baggage of the headers from the 1990ies.
The RFC7235 syntax for
WWW-AuthenticateandAuthorizationuses,(commas) to separate key-value pairs rather that semicolons as many other header fields and as suggested by RFC8941 for new header fields. This means that one has to be very careful when parsing concatenatedWWW-AuthenticateorAuthorizationheaders. This was discussed in Clarify multiple authorization header behaviour or concatenation method issue on the http-core repo in Nov 2018. I am not 100% sure what the result of that discussion was.We have potentially a few Authentication methods we would like to allow. At least:
Basic,Bearer(for Solid-OIDC I guess, but the spec does not make that clear), andHttpSig(that name is not settled as it could also beSignatureas it was used to be with draft-cavage) for HttpSig Authentication.We need to make sure they play well together. Is this problem overcome with HTTP/2.0? One could also use new authentication headers that don't come with the baggage of the headers from the 1990ies.