[db-wg] Proposal about personalised authorisation

The RIPE NCC has discussed the concept of personalised authorisation on various occasions, most recently at the DB WG session at RIPE 69. Following discussions and input from the working group we would now like to propose the following additions to the RIPE Database:

= Extend the person object template with "auth:" as an optional, multiple attribute, with all current authentication methods.
= Extend the mntner object "auth:" attribute with a new method that allows a reference to a person object that has at least one "auth:" attribute.

There is no requirement to use these extensions, but users that choose to  do so can benefit from the following advantages:

= Currently it is is not always clear who uses the credentials in each "auth:" attribute on a mntner. There are two main problems with this. First of all this can result in authorisation being given to the wrong users, and second this makes it difficult to keep these objects up to date. For example it is not easy to remove the password for a specific user from a mntner without knowing, or deducing, which password hash is theirs. Having explicit references to person objects will make this clear.
= Users who are authorised for multiple mntners will be able to maintain their own credentials in one place.
= Audit logging can be improved. It will become possible to show to authorised users of the database which person made which change to their object.
= The security of regaining lost access to a maintainer can be improved by letting users of the database reset the credentials on their own person object, rather than on a maintainer. Especially when the person object is linked with a Single Sign-On account.

Allowing "auth:" attributes on person objects also allows us to make it easier for users to manage their person object in the RIPE Database in combination with their Single Sign-On (SSO) account on RIPE NCC Access as a single identity.

To facilitate this we propose the following:
= Being they are part of the same identity, person objects can only be associated with one SSO account, and vice versa.
= Associated person objects and SSO accounts are automatically kept in sync.
= SSO accounts can associated with new person objects, or existing person objects, provided that the user has access to both the SSO account and at least one maintainer of the person object.
= Users will be able to decouple their own SSO account and person object.