Best practice when creating a new participant

[lauramartingonzalezzz]

Hi,

I saw both on the code itself

IdentityHub/extensions/api/identity-api/participant-context-api/src/main/java/org/eclipse/edc/identityhub/api/participantcontext/v1/unstable/ParticipantContextApiController.java

Lines 64 to 71 in f4ab954

	@Override
	@POST
	@RolesAllowed(ServicePrincipal.ROLE_ADMIN)
	public CreateParticipantContextResponse createParticipant(ParticipantManifest manifest) {
	participantManifestValidator.validate(manifest).orElseThrow(ValidationFailureException::new);
	return participantContextService.createParticipantContext(manifest)
	.orElseThrow(exceptionMapper(ParticipantManifest.class, manifest.getParticipantId()));
	}

and on the MVD repository that only participants with "admin" role can create new participants. Following the example/extension provided by the MVD repository, we obtain a Super-User/Admin-User which would be, in this case, in charge of creating new participants.

But how can I feed this super user with the information needed to register/create a new participant (without it being hardcoded)? Is there a best practice?

Maybe a new extension that provides a custom API before the Identity API? Should it be done manually by the administrator (for example, sending a request of registering with the basic information via email)?

Thank you!

[paullatzelsperger]

the "admin" role is hard-coded in IH, please read this. However, IH does not create any users, so it also does not create an admin user out of the box. This is because it cannot make an assumption of how that is done, when it is done or what the name of that user would be.

MVD simply takes a short cut in seeding the "super-user", and only uses its API key to automatically populate the database.

In practice, this could be a human user, who then manually creates participant contexts, or it could be a technical user, e.g. a script or an application that populates IH with participant contexts. Either are valid use cases, and will 100% depend on your use case.

How that administrator receives participant context information is outside of the scope of IdentityHub. In many cases this will likely be a separate application through which participants "onboard" or register with IdentityHub, but it could be as pedestrian as calling someone by phone, or sending them an email.

[lauramartingonzalezzz]

Thank you so much! Everything is much clearer now!