Token presentation headers

[jricher]

§7 Using Access Tokens: Editor's note:

I don't actually like the idea of using only one header type for differently-bound access tokens. Perhaps instead these values should somehow reflect the key binding types. Maybe there can be multiple fields after the "GNAP" keyword using structured headers? Or a set of derived headers like GNAP-mtls? This might also be better as a separate specification, like it was in OAuth 2. However, access tokens should be able to use any key binding mechanisms here, plus bearer.

[fimbault]

Note that structured http headers now have a RFC https://www.rfc-editor.org/rfc/rfc8941.html

[jricher]

Currently discussed options:

• keep GNAP and have the API look up the binding mechanism and proof it that way
• use a different keyword for each type: HTTPSig, MTLS, JWS, etc.

[jricher]

No real consensus to use different scheme types and instead have things tied to the token's own internal identity. The proof methods don't use parameters on the authorization header, either, so no need to overload this.