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.
"[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...
cheers
denis
co-chair DB-WG