17 docs tagged with "Issuer"

When designing solutions for the EUDI Wallet Ecosystem, both Relying Parties (RPs) and European Accessibility Act. Providers must consider accessibility requirements that ensure their services are usable by all citizens, including those with disabilities. This document outlines the high-level accessibility frameworks and key considerations for designing accessible solutions.

OpenID4VP gives Relying Parties several mechanisms for checking different types of binding. Which of them work for a given credential depends on the features the issuer provided at issuance time and the relying parties use case:

This page aggregates relevant changes in the German EUDI ecosystem for Relying Parties and EAA Issuers. Where possible, upcoming changes are listed in advance so that integrators can prepare.

Claim binding lets a Relying Party check that the presenter still controls a specific piece of identifying data you bound to the credential at issuance, by comparing a claim you copied into the credential against a fresh presentation of the credential you originally drew it from. A vehicle registration credential can carry the vehicle identification number copied from the vehicle's own registration document; a professional credential can carry the holder's name copied from the identity document used to identify them. Checking the copied claim against a fresh presentation of the original tells the Relying Party that the presenter genuinely still controls the identity or object the claim represents, not merely that they hold a copy of your credential.

How to configure the appearance of an Electronic Attestation of Attributes (EAA) so it renders correctly and legibly in the German EUDI wallet.

Audience: EAA Providers running an issuance service in production. This is phase 4 of the EAA Provider roadmap — what happens after you have built and tested your issuer.

Audience: EAA Providers implementing issuance flows with OpenID4VCI in the German EUDI Wallet Ecosystem.

This guide provides EAA-specific onboarding requirements and technical integration steps for organizations that want to issue Electronic Attestations of Attributes (EAAs) in the German EUDI Wallet Ecosystem.

Audience: Developers new to the EUDI Wallet Ecosystem who need to understand how high-assurance credential issuance works in practice.

Audience: Developers new to the EUDI Wallet Ecosystem who need to understand how low-assurance credential issuance works in practice.

Whether you plan to verify credentials (Relying Party), issue credentials (EAA Provider), or do both, you complete the same onboarding process once. During the Plan stage, simply declare all the roles you intend to fulfill in your use case description.

Key binding - also known as device binding - lets a Relying Party check that the entity presenting your credential is the same entity you issued it to, by requiring that entity to prove control of a device-bound key you bound to the credential at issuance. Without it, a Relying Party can only confirm that a credential is authentic: signed data can be copied exactly, out of a backup, off a compromised device, or out of a badly secured log, without invalidating your signature.

Welcome to Germany's EUDI Wallet Sandbox. After your kick-off call, complete the following steps to get access to all resources.

A rulebook is the definitive, human-readable, technical, and governance specification for a credential type. It ensures that relying parties understand exactly what a credential contains, how it's issued, and how to verify it.

1. Geltungsbereich

Diese Use Policy ergänzt die SPRIND EUDI Wallet Sandbox Nutzungsbedingungen und gilt für alle Teilnehmer in den im Zusammenhang mit der Sandbox stehenden Kommunikationskanälen. Das Ziel ist die Förderung einer professionellen, konstruktiven und respektvollen Testumgebung.

Developers testing with the National EUDI Wallet in the Sandbox should be aware of the following details, peculiarities and known bugs.