autograph should make it possible to look-up available keyids for a signer

[bhearsum]

As I understand it, keyids are not secrets. As an autograph user, it would be useful to be able to look up which ones are available for a particular signer, and perhaps be able to look up available signers as well. @escapewindow had a couple of ideas, including:

1. Simply document them in this repo
2. Have an available endpoint that returns them (eg: /signers to get signers and/or /signers/foo to get keyids for the foo signer)

Feel free to close this as undesirable if we the current obfuscation is wanted :)

[g-k]

Per the signing meeting discussion earlier this week, Hal and I didn't think there would be any issues with exposing the keyids the current user already has access to.

Autograph edge pins a keyid, so we initially thought it would not support the new endpoint. However, it might be handy to have edge proxy an API token authed request to the same endpoint. mozilla-services/autograph-edge#9 is a similar issue.

The autograph API is already unprefixed and over JSON. I think it's OK to stick with that.

A few implementation options come to mind:

A) Add an authed GET /auths/:hawk_id/keyids endpoint with the following behavior

• returns 400 Bad Request when hawk_id does not match the signer ID format (checked here which should be extracted as a validator)
• returns 401 Unauthorized when auth fails
• returns 403 Forbidden when the path hawk ID does not match the HAWK ID from the auth header (i.e. I don't have permission to get keyids for other signers)
• returns 200 OK when auth is valid and the path ID matches the auth header HAWK ID containing an array of key ids the signer has access to e.g.

[
  "key-signer-id-1",
  "key-signer-id-2",
  ...
]

We can probably avoid worrying about pagination or filtering, since the responses are small and signers usually have access to a handful of key ids.

Optionally, the monitor ID could return all signers we're monitoring.
Optionally, nginx could cache the responses (since the config is static).

B) Alternatively, a GET /my/keyids with similar behavior to save adding the :hawk_id to the URL path in addition to using it to build the auth header.

C) return keyids in a HEAD response to /sign/{data,file,hash} URLs possibly in a header like X-ALLOWED-KEYIDS. This would save adding a new endpoint path.

D) return allowed keyids in 403 responses to sign requests. Relatively simple, but complicates the signing handlers and sorta weird to require an invalid request to get data back.

We could also include more data in the responses e.g. including a object with the signer config and options.

[g-k]

I don't have a strong opinion on the options, but I'd be curious in feedback from on the server (what do we want to maintain) and client perspectives (do you have a preference on what you'd want to implement in signing-scripts).

f? @bhearsum @ajvb

[bhearsum]

Our use case is largely for humans, I believe - I don't think we were planning to implement anything in signingscript (although I suppose we could, as a sanity check before making a signing request).

D feels weird to me. All of the other options seem roughly equivalent.