<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Arial">Marcus/All<br>
<br>
</font>I endorse a common key generation/signature platform ...<br>
(openSSH provides machinery for this kind of thing, but there
should be<br>
a webserver (Apache?) authentication module for whatever IVOA
prescribes:<br>
The services only need proof that the client _has a valid
service key_<br>
the key should probably NOT be sent to the services ...<br>
as it is likely these api keys will be ... "long-lived" ...</p>
<p>I further second the "adopt an existing deployed mechanism"
criteria.<br>
<br>
WebAuth is rather over complicated for IVOA, but it is an
existing standard,<br>
capable of being leveraged at a data-center level, but I
doubt the average<br>
PI/project team will have the willingness to do alot more
than<br>
systemctl enable apache2 ...<br>
???<br>
<br>
I would like to point out, that the reason NED uses special keys
at all<br>
is <i>specifically to _get_ an email, or reliable contact
information.</i>..<br>
(In the NED case, if we can't contact them, we don't need keys
at all.)<br>
</p>
<p> But, If a user wants special access, in the form of increased
resources,<br>
("I need to do 20 million queries to NED in the next 3 days").</p>
<p> we must be able to <br>
1) identify the user from the request, so as to authorize them
for the up-lift,<br>
(unique key for this user, with contact information _we_<br>
have verified. "We" could be an IVOA registry.); AND<br>
<br>
2) NED must be able to contact <b>the user</b> in the event of
issues (always),<br>
<br>
Otherwise our only options are to shut them down,<br>
or let them deny services to the rest of the community (which,
um, no.)<br>
<br>
A few key generating services each with a distinct signing key,
and published<br>
"CA certificate" <br>
(you see where I'm going -- this kind of authentication
problem has been solved<br>
with client certificates, revocation lists, etc.<br>
simple? no, but federated identification and authentication
is not simple.<br>
<br>
I would ask that if there is no identification ... <br>
</p>
<div class="moz-signature">
<hr style="width:30%;text-align:left;margin-left:0">
<div>
<span style="color:rgb(105,107,115);font-family:Arial, sans-serif;font-size:12px">
<b>Rick Ebert</b> <br>
Segment Manager | </span><span style="color:rgb(255,108,12);font-family:Arial, sans-serif;font-size:12px">Caltech/IPAC</span><br>
<span style="color:rgb(105,107,115);font-family:Arial, sans-serif;font-size:12px">Engineering
Group Lead | NASA/IPAC Extragalactic Database</span><br>
<span style="color:rgb(105,107,115);font-family:Arial, sans-serif;font-size:12px">Mail
Code MR-100 | Pasadena CA 91125</span><br>
—<br>
<span style="color:rgb(105,107,115);font-family:Arial, sans-serif;font-size:11px"><i>“…
and so, you can never catch up.”</i></span><br>
<span style="color:rgb(105,107,115);font-family:Arial, sans-serif;font-size:11px">–
Zeno of Elea, (The Tortoise and Achilles)</span><br>
</div>
</div>
<div class="moz-cite-prefix">On 11/21/24 12:45 AM, Markus Demleitner
via ops wrote:<br>
</div>
<blockquote type="cite" cite="mid:20241121084552.6istuaql2fzfwzcz@victor">
<pre wrap="" class="moz-quote-pre">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
_______________________________________________
ops mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ops@ivoa.net">ops@ivoa.net</a>
<a class="moz-txt-link-freetext" href="http://mail.ivoa.net/mailman/listinfo/ops">http://mail.ivoa.net/mailman/listinfo/ops</a>
</pre>
</blockquote>
</body>
</html>