Where does a credential need to work?
The intended reach of a credential determines which parties the agreements need to cover.
Within your own organisation
Your organisation arranges both issuance and use. A university could confirm an exam registration that is checked at entry to its own exam. Different departments and systems follow the same agreements.
Between established partners
A group of organisations agrees which credentials it accepts from each other. Each partner needs to recognise the issuers and understand the requirements their credentials meet. Joining, leaving and communicating changes also require shared agreements.
Across a wider ecosystem
Participants use shared rules to assess issuers and credentials, even if they have not worked together before. It must be clear who maintains the rules, how participation is established and for which purposes credentials are accepted.
Reach alone does not determine the appropriate technology, certificate type or legal category. The right setup also depends on the data, risks, existing systems and applicable requirements.
Which agreements and responsibilities are needed?
A trust framework makes clear what participants can expect from each other. Responsibilities may sit with different parties, but one organisation can also fulfil several roles.
The source owner maintains the data on which the credential is based. The issuer confirms a claim using that data and issues the credential. This requires an agreed basis for issuance: suitable sources, necessary checks and the types of credential for which the issuer is accepted.
The wallet user shares data from the credential. The verifier performs the agreed technical checks. The organisation using the data assesses its suitability for its decision under the applicable rules. Technical validity alone does not establish that all source data is correct.
ARF 3.0: roles and trust relationshipsAn exam registration, from source to use
It must also be clear who maintains the shared agreements and how compliance, incidents and changes are handled. Where issuance or verification is outsourced, the technical operator’s tasks are distinguished from those of the issuer and the organisation using the data.
How are the rules for a credential documented?
A rulebook describes the meaning, data and rules for a digital credential. It brings together three elements.
Meaning and data
What claim does the issuer make, who or what is it about, and which data belongs with it? For an exam registration, it must be clear which exam and date are meant.
Issuance, use and management
Which issuers and sources are accepted? Which checks precede issuance, how long can the credential be used, and what happens when something changes?
Technical specifications
Which formats and exchange protocols are used, and how is data encoded and checked? Corresponding technical definitions make these elements processable by systems.
The rulebook can reuse existing framework agreements and standards, refer to them and record additional rules.
ARF 3.0: rulebooksHow are parties and credentials checked?
The verifier must be able to link the received data to an issuer trusted to make the claim in question.
Origin and keys
For a digitally signed credential, the verifier uses a public key to check whether the signed data is unchanged. There must also be a reliable basis for identifying the issuer to which that key belongs. Several building blocks can support this.
| Building block | Function |
|---|---|
| X.509 certificates | Bind a name to a public key. A certificate chain is validated up to a previously accepted trust anchor. |
| Managed registries | Publish information about participants, their keys and their admission to the framework. The signed registry of a Yivi scheme is one example. |
| OpenID Federation | Connects participants through signed information and policies governing their technical metadata. |
| DIDs | Can make verification keys discoverable. The link to an organisation and its authority requires separate substantiation. |
These building blocks can be combined. An organisation can also directly manage the keys of known issuers.
From received credential to assessment
The exchange and the credential
Identifying the service a wallet communicates with is a separate check from checking the credential itself. The EUDI model uses access certificates for this identification. Registration does not automatically confer authority to issue every type of credential or request data.
Depending on the setup, checks also cover the validity period, revocation status and required binding to a wallet or user. Acceptance rules connect the results to the intended use.
ARF 3.0: technical trust relationshipsHow do eIDAS and EUDI fit in?
eIDAS provides the European legal framework for electronic identification and trust services. The EUDI wallet ecosystem connects wallets, issuers and organisations within that framework. The ARF describes the architecture; legal obligations follow from eIDAS and the applicable implementing rules.
The legal categories
EAA stands for electronic attestation of attributes. Whether a digital credential falls under eIDAS depends on the specific setup and the legal scope.
| Category | Defining feature |
|---|---|
| Non-qualified EAA | An attestation without qualified status, still subject to the applicable legal obligations. |
| QEAA | An attestation meeting the qualified requirements, issued by a provider qualified for this issuance service. |
| PuB-EAA | An attestation from a public sector body responsible for an authentic source, or a public sector body designated by the Member State to issue on behalf of such source owners. Specific requirements, conformity assessment and notification apply. |
QEAA and PuB-EAA have the same legal effect as lawfully issued paper attestations. An EAA cannot be denied legal effect or admissibility as evidence in legal proceedings solely because it is electronic or non-qualified.
Official recognition and trusted lists
For QEAA, check the qualification of the specific issuance service. Member States publish Trusted Lists of providers and their qualified services. The European Commission publishes the List of Trusted Lists (LOTL), with pointers and information for authenticating the national lists.
Separate recognition and listing mechanisms apply to providers of person identification data (PID) and PuB-EAA. For non-qualified EAA, the ARF recommends documenting in the rulebook how trusted signing anchors are obtained.
The applicability of eIDAS must also be assessed outside EUDI. Article 2 provides an exception for trust services used exclusively within closed systems based on national law or agreements between a defined group of participants. Internal use alone does not establish that this exception applies.
eIDAS: scope, categories and trusted listsHow can different setups serve the same purpose?
A university wants to give a student a credential about their exam registration. The claim to be confirmed remains:
This student is registered for this exam.
The university maintains the source data. The setups below are illustrative; each requires suitable agreements, legal conditions and technical support.
| Setup | Issuance and recognition |
|---|---|
| University via EUDI | The university issues a non-qualified EAA. The verifier accepts it as the issuer for this claim and uses the agreed signing anchors. |
| Qualified issuance via EUDI | A provider qualified for this service performs the required checks and issues a QEAA. The university remains the source owner. The service and signing anchors are identified through the official trusted lists. |
| University via Yivi/Idemix | The university issues within a scheme that admits its key and the relevant credential type. The scheme manager publishes that information in signed form. |
Example · One exam registration, three setups
The university issues directly
- Recognising the issuer
- Agreed signing anchors
A qualified provider issues
- Recognising the issuer
- Qualified service in the Trusted List
The university issues within a scheme
- Recognising the issuer
- Signed Yivi scheme registry
For the EUDI setups, the chosen formats and protocols must align. The Yivi example specifically uses Idemix and the IRMA protocol. Yivi also supports SD-JWT VC through OpenID4VP; the wallet name does not determine the legal category.
Yivi: Idemix and OpenID4VPAt entry to the exam, the credential must confirm the required registration. If the student later withdraws, that change must also be able to inform a subsequent check.
How is trust kept up to date?
A change at the source does not change the signed content of an existing credential. Issuance, source management and checks at use must therefore remain aligned after the first exchange.
Handling changes
The agreements determine how the issuer identifies relevant source changes and their consequences. Depending on the setup, the credential can be revoked, expire or be replaced. A new credential does not automatically invalidate the old one.
Revocation changes the validity status. The credential can remain in the wallet and earlier exchanges continue to exist.
Example · The student withdraws
Credential in the wallet
This student is registered for this exam.
The signed content remains the same in every state.
Registration active
- Source records
- Student registered
- Status at the issuer
- Not revoked
- Information at the verifier
- Sufficiently recent status checked
The registration is active. The verifier has status information meeting the agreed freshness requirement.
Source changed
- Source records
- Student withdrawn
- Status at the issuer
- Change not yet processed
- Information at the verifier
- Status information predates the change
The source has changed, but the issuer has not yet processed revocation. The verifier still has information from before the change. This example shows why freshness requirements matter.
Revocation checked
- Source records
- Student withdrawn
- Status at the issuer
- Revocation published
- Information at the verifier
- Current revocation checked
The issuer has published the revocation and the verifier has checked the new status. Under the agreed rules, this credential no longer grants access to this exam.
Using current information
The verifier uses status information according to the agreed requirements. It must be clear how old that information may be and what happens when it is unavailable. During offline use, the last available status may already be out of date.
Keys, certificates and participation can also change. Systems must incorporate relevant changes into their trusted information. The status of a credential and that of a signing certificate remain separate checks.
Maintaining the agreements
When the rulebook or framework rules change, it must be clear when the change takes effect, who informs participants and which rules continue to apply to existing credentials.