Consider adding an example with keyId using a URL

[csarven]

The RSA and HMAC examples are very similar. It'd be useful to add a bit more diversity by adding an example with keyId="<url>". Alternatively, if having fewer examples is preferred, consider replacing HMAC examples with URL, and/or something else.

[bblfish]

I think @csarven actually came up with a good notation to help a server distinguish an id that is a URL that could potentially be dereferenced and others, namely to put the id in < and >
brackets.

So imagine that I want to access a page at https://accomodation.soton.ac.uk/request/ to request accommodation but that I need to authenticate first to do this. I may have created a keyid with the service previously, but perhaps I can also use one I already generated with another department at the university of Southampton.

• keyId="ae45ds" is understood to be something generated directly by that server (and that cannot be used further than that server)
• but keyId="<https://engineering.soton.ac.uk/keys/aed34df>" is something that allows different departments to build their key server without needing to rely on a centralized service. I think this example would be even stronger for a university like Oxford or Cambridge, where colleges are very proud of their independence. (The server can have policies about whether it accepts keys outside of its domain, and that is left to another spec)

Relative URLs could then also be allowed such as keyId=</keys/aed34df> when authenticating directly to pages in the https://engineering.soton.ac.uk domain. This also makes it possible then to generalise the use of keys to other protocols involving blockchains, etc... In fact any URI should do.

[msporny]

put the id in < and > brackets

The spec treats the contents of keyId as opaque data on purpose and enables specs higher up the chain to describe what is and isn't allowed for keyId. We're trying to keep "smarts" out of this spec and push it up to higher level protocol specs.

So, another spec could specify that < and > have special meaning in keyId, but the Signing HTTP Message spec shouldn't do that for extensibility purposes.

[msporny]

It'd be useful to add a bit more diversity by adding an example with keyId=""

Agreed, I'll try to do this in the next revision. Keep in mind that we're trying to keep the spec very short, so I may add the example and determine that it's a lot of text just to note that you can use a URL in keyId. :)