This can be addressed by assigning the SecurityAdmin role to the Anonymous user in TOFU/setup state. Once the GDS assigns its ApplicationUri to the SecurityAdmin role, it removes the assignment to the Anonymous user.

Subsequent updates to TrustLists or Certificates can be allowed if the Client has a trusted Certificate has access to the SecurityAdmin Role. During the setup state the Client should configure the SecurityAdmin Role. If the Client fails to do the, the Server should grant SecurityAdmin rights to the ApplicationUri used by the Client to setup the Server.

Needs more work.

add When a Server is in the “setup state” it shall limit the available functionality.

and assign the SecurityAdmin Role to Anonymous user if the TrustList is empty;

Need to move TOFU text from Part 21 in a future release.

Agreed to changes in Virtual F2F.

I think we need some further clarifications

(1) Order of configuration
Since we say that the mode is only valid for 'empty TrustList', a client must first configure the SecurityAdmin role and then configure the TrustList

(2) ServerState
We are silent about the ServerState.
It makes sense to define the value of the ServerState in the "setup state". It could be NoConfiguration or Suspended

There is another issue with the "setup state". The actual state is unknown until the client has created a Session. If a configuration client has stored a user that was created for administration, this user is no longer available after a factory reset. A client would need to create a Session with Anonymous to be able to connect and to find out that the server is in provisioning mode. But a client that was connected before would not fall back to Anonymous.

One option would be to return somthing like Good_ProvisioningMode in CreateSession. This would allow a client to go into a special mode for provisioning.

Added requirements for ServerState and a new InSetupState property.

Agreed to changes edited in Web meeting.