Revoking signature-based authentication

[Acconut]

The draft recommends revoking credentials if they are received over an insecure channel. This makes sense for requests which directly include an API key, for example as a Bearer token, because an eavesdropper can directly see and abuse the API key.

Another common form for API authentication is using an authentication pair consisting of a pair ID for identifying the user and a secret, which is only known to the service provider and the user. An authenticated request then includes the pair ID and a signature generated with a HMAC and the secret. The request does not directly include the secret. AWS uses this approach, for example.

If an attacker eavesdrops on such a request, they obtain knowledge about the pair ID, but not the secret. While leaking the pair ID may not be ideal, obtaining the ID and signature does not allow an attacker to abuse the authentication pair and forge signatures. Should in these cases the authentication pair still be revoked? Should the draft distinguish between requests that directly include the secret credentials and those which include signatures?

[richsalz]

So instead of key material, a key identifier is passed. I agree that it is reasonable to send that in the clear. The text should make it (sic) clear that sending a key identifier is NOT the same as sending a key, and that this can be okay.

[Acconut]

Opened #10 to add this to the document.