DevPortalPagoPA



Tabella dei contenuti

Operations and lifecycle

Creating a draft and submitting the request

A party can subscribe to the e-services available in the e-service catalog when both of the following conditions are met:
  • the party does not already have an active service request for the same e-service;
  • the party possesses the minimum requirements for subscription (required attributes).
The platform allows the creation of a draft only if all required certified attributes for the e-service are satisfied. The potential consumer is responsible for:
  • self-declaring the required declared attributes;
  • uploading the documentation necessary for the producer to verify any verified attributes.
Once the draft is completed, the request can be submitted to the producer for approval.

Subscribing to one’s own e-service

A party can subscribe to its own e-services as a consumer without the attribute verification phase. This mechanism simplifies monitoring activities and reduces administrative burdens in cases of self-consumption.

Approval or rejection of the request

The approval policy is configured in the e-service version and can be:
  • Automatic: PDND performs the verification; if the consumer possesses all required attributes (certified, verified, declared), the request is activated immediately; otherwise, it enters the manual approval flow.
  • Manual: the producer activates the request after performing its own verifications (including the evaluation of verified attributes).
The producer may reject the request if the requirements (attributes) are not met and must justify the decision.
The consumer may then submit a new request, updating the documentation and/or justifications.
For any clarifications, the producer’s contact information is available on the e-service page.

Updating a service request

An update is required when the producer publishes a new version of the e-service. The consumer will find the option to update directly on the request’s page.
Each request is linked to the specific version it was created for: if it was submitted for version 5, when the e-service is upgraded to version 6, it must be updated. Upon updating:
  • All purposes are migrated to the new request without changing the purpose’s technical ID (purposeId);
  • From that moment, they use the new e-service version;
  • The operation is irreversible.
It is considered good practice to review the changelog and updated interface files to understand any modifications, especially if there are possible “breaking changes” in access requirements or API structure.
If the producer publishes multiple versions, the update always applies to the latest one.
For example, if the consumer is on v3 and the producer releases v4 and then v5, the update takes the consumer directly to v5.
Some e-services offer a testing environment version, allowing pre-production testing before adoption in the production environment.

Archiving a service request

Archiving can occur in two ways:
  • Automatic: when the consumer updates the request to the latest e-service version, the request for the previous version is archived, and its purposes are linked to the new request;
  • Manual: initiated by the consumer when the service is no longer needed.
    Later, a new request may be created, provided that no other active request for the same e-service exists.
For order and security, it is considered good practice to archive requests for e-services that are no longer in use.

Suspension and reactivation

Suspension may be initiated by the producer, consumer, or platform.
If any actor suspends, the request is considered suspended.
Only the actor who applied the suspension can lift their own suspension.
Suspension rules
  • Producer: may manually suspend a request.
  • Consumer: may manually suspend a request.
  • Platform: suspends a request when it detects that:
    • the producer has revoked one or more verified attributes from the consumer;
    • the consumer has self-revoked one or more declared attributes;
    • an authoritative source or certifying body has revoked one or more certified attributes.
To reactivate a suspended request, all actors who suspended it must lift their suspensions, and all required attributes must again be recognized.
Example: if the producer attempts to reactivate a request for which it revoked a verified attribute, reactivation will not succeed until the attribute is verified again.

States

The following table summarizes the states a service request can assume and their operational impact:
StateDescriptionAllowed actions
DraftRequest in progress, not yet submitted to the producer.The party can fill in the form, self-declare required attributes, upload documentation for verified attributes, and delete the draft. The request can be submitted once all minimum requirements are met.
Waiting for approvalRequest submitted to the producer for review and potential activation.Activation occurs manually by the producer or automatically by the platform, depending on the policy set in the e-service version.
ActiveRequest activated (by the producer or platform, based on the policy).Allows the creation of new purposes for the e-service. The request can be suspended or archived according to the applicable rules.
SuspendedTemporarily disabled by the producer, consumer, or platform.Each actor that applied a suspension can lift their own. The request becomes operational again only when all suspensions are lifted and requirements are satisfied.
ArchivedThe consumer has withdrawn the request because the service is no longer needed.A new request can be submitted in the future, as long as no other active request for the same e-service exists.
Missing certified attributesTechnical state applied when the party loses one or more required certified attributes while the request is in draft or waiting for approval.The platform blocks submission until the authoritative source or certifying body reassigns the attribute. Alternatively, the consumer may delete the draft.

Next page → Purposes

Hai bisogno di aiuto?

Apri un ticket utilizzando l’apposita funzione all’interno della tua Area Riservata

Dicci cosa ne pensi

Per segnalare problemi o dare feedback, puoi aprire una segnalazione su Github