<div dir="ltr">Hi Tore, WG,<div><br></div><div>I really do not see any benefits or reasons why we should change the API key system for the DB.</div><div>Maybe I am missing something that you can elaborate on.</div><div><br></div><div>Additionally if this was to replace the existing system it would just make it unavailable for non-LIRs (such as orgs with PI resources) without any real reason.</div><div><br></div><div>- Cynthia</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 21, 2020 at 11:54 AM Tore Anderson via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi WG.<br>
<br>
In the LIR Portal, at <a href="https://lirportal.ripe.net/api/" rel="noreferrer" target="_blank">https://lirportal.ripe.net/api/</a>, it is possible to issue API keys for use with several different RIPE NCC services.<br>
<br>
However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW.<br>
<br>
I propose that the API keys mechanism is extended to Syncupdates and the RESTful API.<br>
<br>
The already existing default maintainer concept could be leveraged to accomplish this (similar to how NWI-8 was implemented). That is, using Syncupdates or the RESTful API with API keys will simply authenticate the client as the LIR's default maintainer.<br>
<br>
Authorisation should remain handled by in-band mnt-* object attributes, as is currently the case.<br>
<br>
It would be an acceptable limitation that API keys for database maintenance are unavailable for LIRs without a default maintainer.<br>
<br>
Assuming the WG agrees that this is a good idea, I request an NWI.<br>
<br>
Tore<br>
<br>
</blockquote></div>