[Ops] VO-wide API keys

[Markus Demleitner]

Dear Ops, dear GWS,

At the recent Interop, IPAC announced they would soon have to
introduce per-user API keys; these are not really for (strong)
authentication, but mainly to be able to throttle overly eager users
and to be able to advise them on good manners via e-mail if
necessary.

Now, it would be bad UX if users and clients had to manage a bunch of
API keys (and methods for how to present them) for the various major
VO services in case more operators went that way.

So, *if* we have to have them, let's make it such that they are
VO-wide from the start.  A single key-generating service (or at worst
very few of them) should hand them out, and hopefully all
API-key-using services would accept them.

The way I think this could work is that the key store generates a uuid
and then signs it; it gets associated with an e-mail address, but
that address is only retained (with the UUID) at the key store.

With ed25519 signatures, the resulting API key would still be compact
enough, I suppose, probably just one text line in base64.  The key
store then publishes the public key of the signing key used, so if I
want to check an API key I just check for a valid signature with that
key and be done with it.  If I really want to uncover an identity,
I'd extract the UUID and ask the key store, which admittedly *might*
incur a minor amount of extra admin work there, but really, I'd be
surprised if these kinds of requests came in more often than once per
week or so.

If we found we needed it, we could even have revocation lists (signed
with that same key), but frankly I think we can think about that when
that turns out to be a use case (which I don't expect).  Perhaps some
sort of built-in expiry could be that we rotate the signing key
every two years or so.  Data centres could then easily validate
signatures for the past six years or choose to just go two years back
by choosing with private keys they use for signature checking (but
I'm not wild about expiring keys, very frankly: crypto is hard enough
without timebombs).

Note that this is not strong authn, mainly because clients would
likely be handing out the API keys to anyone on request, and then
anyone operating such a service could collect API keys.  We *could*
make it so the service has to prove something to the client before
the client hands out the API key to mitigate the problem of API key
stealing, but frankly, I'm sure that's overengineering for the sort
of thing we want to do here (control users overstressing our services
without evil intent; perhaps control access to persistent TAP
uploads).  If you want an API key, go to the key store, and the
benefits of having someone else's API key look very minor (well: if
we did persistent uploads by API key, you could read other persons'
tables.  Hm).

If some system like this already exists in the wider Web, even better
(I have to admit I have largely given up following all the
adventurous schemes for Web Authn and its environs).   Then let's
just adopt that.  But if not, I think this would be a nice, quick,
and simple way to have a halfway privacy-respecting solution for the
overeager user problem.

I'd be in on writing a short Note hashing out the details.

Thanks,

                     Markus