HttpSig, Signature, or Solid?

[bblfish]

In the current HttpSig proposal I suggest using

Authorization: HttpSig

header. In @msporny and @mcavage-stripe's draft-cavage from version 02 onwards, the following header was used:

Authorization: Signature ...

We could use Signature as before, except that

1. cavage never specified the format to indicate that the keyId should be a URL as we do by specifying the syntax <...> and >...<
2. The Signging HTTP Messages draft places all the information that previously was placed in the Authorization header in two different ones Signature-Input and Signature

Signature-Input: sig1=("@request-target" "host" "date"
      "cache-control" "x-empty-header" "x-example"); keyid="test-key-a";
      alg="hs2019"; created=1402170695; expires=1402170995
Signature: sig1=:K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUe\
      Zx/Kdrq32DrfakQ6bPsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibe\
      oHyqU/yCjphSmEdd7WD+zrchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4\
      CaB8X/I5/+HLZLGvDiezqi6/7p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg\
      1Q7MpWYZs0soHjttq0uLIA3DIbQfLiIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZg\
      FquQrXRlmYOh+Hx5D9fJkXcXe5tmAg==:

which means that in any case the whole Authorization header will need to be rethought, meaning that using Signature could lead to confusion with existing implementations. Point 1. above could otherwise have been solved by adding a solid attribute to the Signature authorization scheme header.

We could also use another field like Authorization: Solid for example. But really we would like this to go beyond Solid. We still have time for us to grow the community and come to informed consensus.