Niels closed issue #138: Refine regulated area extension at Common Ground / NLX / FSC NLX

Niels
2025-01-21T12:36:11Z

See the following issue for more information: #374

Requirements

It must be possible to automatically grant access to a Service based on membership

It must be possible to automatically deny access to a Service based on membership

Only an member of a regulated area is allowed to publish a Service

The maintainer (membership administrator) of a regulated area must be able to add/remove Peers from the regulated area

When a Peer is removed all Services of the Peer must be removed from the Directory

The membership list should be a separate endpoint. /peers is defined in core and we should not change it. /members ?

Add test cases when defining the extension of the standard. Core should support multiple areas. Ledenadministratie should ensure managers should not be able to interact with area's you are not a member of.

Questions

In case of delegation must all Peers be part of the regulated area? -> Yes

Ask FDS why the membership administrator should be able to view the transactionlog. -> no, the membership administrator is a different role then the authority that should be able to view all transaction logs is out of scope for the "regulated areas extension"

It seems that the membership administrator cannot change without creating a new regulated area. -> no, however when the membership administrator changes the members of the regulated ares should create a new PeerRegistrationGrant with the new membership administrator.

Should the regulated area support be optional in the reference implementation? -> no, in the reference implementation the extension should be built in just like with the logging extension

remark, investigate as a nice to have how much effort it would take to hide the controller ui features of an extension when an extension is not active/not available

Remark: the directory of the regulated area should be "viewed" by everyone. That means also peers that are not a member of a regulated ares should be able to view the services published in a regulated area. However, only peers that are member of a regulated ares are able to publish a service in a directory in the regulated area.

Considerations

Options for adding the membership administrator on Contracts:

Add new Grant types.

Add a field to existing Grants

Add to the Contract itself

Add new Grant types. E.g. serviceConnectionRegulatedArea

No need to update Core, functionality is scoped within extension

If we introduce new grant types for every extension, we might have to support 30+ grants in a couple of years

Add a field to existing Grants. E.g. serviceConnectionGrant.membershipAdministrator

Easy to implement

Changes Grants defined in Core. Core cannot change without reviewing the compatibility of Grants

Add to the Contract itself. E.g contract.content.membershipAdministrator

No need for extra Grants or modifying existing Grants

It becomes impossible to mix regulated areas on single Contract. Is this what we want?

Should the FSC NLX implementation hard code support for regulated areas or as optional?

---