EUDI relying-party registration data: what the technical model now contains

Registration starts with the organisation but does not end there

The European Digital Identity framework requires relying parties to register when they intend to rely on EUDI Wallets for digital services. The minimum model includes establishment, official identity and contact information.

The technical specifications go further by describing relying-party services, intended uses, privacy policies, requested credential information and other machine-readable context.

Intended use is a first-class data structure

TS05 and TS06 model intended use as more than free text. The current technical model includes a purpose, privacy-policy references and credential information describing what the service intends to request.

For product teams, that means an intended use can be treated as configuration that is validated, versioned and connected to presentation requests.

• Organisation and official identifiers.
• Relying-party service identity and description.
• Intended-use identifier and purpose.
• Privacy-policy URL for the intended use.
• Credential formats and requested claims.
• Entitlements and public-sector indication where applicable.
• Intermediary association where applicable.

The registrar interface is machine-readable

The relying-party registration rules require information to be available through both human-readable and machine-readable interfaces. The technical specification defines a common REST API using OpenAPI and JSON with signed output.

That creates opportunities for operational tooling to synchronise registration context rather than relying entirely on manual configuration.

The 2026 update matters for existing designs

The 2026 amendments changed the registration framework and the common data set, including explicit treatment of intermediary relationships and registration certificates.

Teams that designed against early 2025 drafts should therefore re-check field names, certificate assumptions and intended-use modelling against the current specification.

Use the data model to constrain runtime requests

The strongest implementation pattern is to connect registered intended-use configuration directly to the verifier. A request should be generated from approved configuration rather than assembled freely by frontend code.

That gives engineering controls the same shape as the registration model and makes accidental overasking easier to prevent.