Thanks Ed. But keep in mind that there is no consensus yet on the final
solution definition the community wants. The discussion has ranged from a
'magic' MNTNER object, to groups of SSO authorisations managed through the
portal UI to Tore's latest suggestion of directly referencing these groups in
the "mnt-xxx:" attributes.
Tore I do like your idea:"[For example, imagine these groups could be
referenced directly in
mnt-by/ref/etc. attributes instead. Then many (most?) LIRs would no longer
need to create any mntner objects at all, they could simply reference
their implicit «all» group directly. This would seem like a more user-
friendly and simple solution than require all LIRs to create a «glue»
mntner object. I don't know if this is doable or even desirable from the
NCC's point of view, but I would like them to have the freedom to consider
such solutions too.]"
Almost anything is 'doable', but it is the communities point of view that is
most important here. The desired solution comes from the community then the NCC
looks at the impact and possible implementation of that solution and may
suggest technical changes.
Using these groups directly in "mnt-xxx:" attributes does take us a step
further in the direction of personalised auth. An issue that has been discussed
several times in this working group. It also keeps more of your security
details private. It eliminates the need for the MNTNER object, which is just a
box holding credentials that the public has no need to see.
As a later extra step we could even include management of passwords and PGP
through the portal UI which could be added to the groups. Then anyone with a
portal account no longer needs to create any MNTNER objects. (I'm not
suggesting that at this stage as that is feature creep which pushes the whole
idea further down the road.)
An extra benefit of this idea is that it is totally optional and backwards
compatible. So anyone who doesn't want to change anything has no need to do
anything.
On a technical note I would also add that we cannot build in a dependency for
the RIPE Database updates on the portal service being available. The RIPE
Database update service has a higher resilience than the portal and must not be
compromised. Therefore the credential groups managed through the portal UI need
to be available to the RIPE Database in an offline capacity or maybe even
stored in some way as private data within the database itself. That is
something for the NCC to think about.
Comments and thoughts from anyone are always welcome...
cheersdenisco-chair DB-WG
On Monday, 18 February 2019, 16:54:06 CET, Edward Shryane
<[email protected]> wrote:
Hi Tore,
the DB team will get started on an implementation proposal for the DB-WG.
Regards
Ed
> On 18 Feb 2019, at 10:05, Tore Anderson via db-wg <[email protected]> wrote:
>
> * denis walker via db-wg
>
>> We had a long discussion on this in January. I don't see any objections to
>> this NWI so I would like the NCC to add this to the web page list of NWIs
>> with the Problem Definition shown below. Can you arrange that Ed?
>
> I can see it's up on the page now.
>
>> Then we can move onto more discussion about the Solution Definition.
>
> In order to avoid design by committee it would be nice to hear an
> implementation proposal from the NCC at this point, I think. Is this
> something that can be arranged?
>
> Tore
>
>
>
