AI translation

This page was translated from German with AI. If in doubt, the German original applies.

Roles and permissions in the SDK

Resolving operator identifiers and deriving from them which steps the logged-in user may perform on a document.

The background in business terms is described in the guide Roles.

Operator as an identity concept

Every party in the document is a WasteOperatorType with two mandatory details: PartyUuid (technical ID) and OperatorInternalId (ID in the DIWASS operator directory, xs:long). A name is not enough — you have to resolve the ID beforehand:

// EORI → matches in the DIWASS operator directory (a list, not a single match)
var hits = await client.DiwassApi.OperatorApi.FindOperatorForEori(eori);

// own operator IDs of the logged-in account
IReadOnlyList<long> mine = await client.MyAccount.GetOwnDiwassOperatorIds();

Permissions in the SDK

The SDK comes with a role-based pre-check. It is a pre-check for user interfaces, not authorization — the decision is made on the server side.

Building block	Namespace	Purpose
Role	Zedal.Sdk.Apis.Diwass.Permissions	the six roles
PermissionMatrix	Zedal.Sdk.Apis.Diwass.Permissions	may this role trigger this operation in principle?
PermissionMatrixInference	Zedal.Sdk.Apis.Diwass.Permissions	which roles does an operator ID hold in this document?
DiwassIntents	Infotech.Zedal.Documents.V1.Zewass.V1	the operation types as an enum — also the content of handler.FollowupIntents

// role-based
bool allowed = PermissionMatrix.CanPerform(Role.Notifier, DiwassIntents.CreateSubmission);

// intersection of "allowed by role" and "allowed by lifecycle"
var usable = PermissionMatrix.Filter(roles, handler.FollowupIntents);

// derive roles from the document and the operator ID
ISet<Role> roles = PermissionMatrixInference.InferRoles(operatorId, handler.Notification);

Both classes also work on role sets: one operator ID can hold several roles at the same time — for example notifier and waste producer.

The allow lists at a glance:

Role	Allowed intents
Notifier	CreateSubmission, UpdateSubmission, CreateReplyToRequestInformation, SubmitRequestForChangeAfterConsent, CreateMovementTemplate, UpdateMovementTemplate, CreateMovementTakeBack, UpdateMovementTakeBack, SubmitMovementSignal, plus the arranger’s four Annex VII intents
Consignee	CreateConsigneeReception, UpdateConsigneeReception and their Annex VII counterparts
Carrier	CreateCarrierTransport, UpdateCarrierTransport and their Annex VII counterparts
WasteProducer	empty
RecoveryDisposalFacility	CreateFacilityReception, UpdateFacilityReception, CreateFacilityCompletion, UpdateFacilityCompletion and their Annex VII counterparts
Authority	CreateRequestInformation, UpdateRequestInformation, SubmitDecision, UpdateDecision, SubmitAcknowledgement, SubmitReplyToRequestForChangeAfterConsent, SubmitMovementSignal

Three peculiarities a user interface needs to know about:

Role.Authority cannot be inferred

PermissionMatrixInference only infers roles that appear as an operator ID in the document. Authorities have none. If you act as an authority, pass Role.Authority explicitly to the role-based methods.

In addition, inference works exclusively on the server view (the Get… information types). Immediately after CreateSubmission and before the first reload, it returns an empty set — the roles are not final at that point, because only the server determines which operator ends up in which slot.

Two SDK methods have no intent at all

SubmitNotificationSignal and SetFacilityCompletionUnderArticle15 have no counterpart in the DiwassIntents enum. As a result, the permission matrix cannot evaluate them, and they do not appear in handler.FollowupIntents either. A user interface that derives its buttons exclusively from the follow-up intents never shows cancellation or the Article 15 certificate.

The matrix is more permissive than DIWASS

The take-back intents (CreateMovementTakeBack, UpdateMovementTakeBack) are in the allow list of Notifier, not in that of Authority. According to the DIWASS specification, however, take-back is an operation of the authorities concerned, and the payload strictly requires an authority domain code and an authority signature.

So for “is this allowed right now”, rely on handler.FollowupIntents — that list comes from the server. The matrix is useful for graying out actions that obviously belong to other roles, not as the final authority.