Wallet Function: PID Issuance and Presentation¶

The PID is an attestation of person identity data and an electronic identity as defined in eIDAS. It can be used by a user to identify themselves at a Relying Party. This section discusses options to present a PID in a remote transaction (incl. authentication).

Requirements¶

The following additional requirements apply to the PID solutions:

the PID and its complete lifecycle, including its issuance and presentation processes, shall fulfill the requirements defined for Level of Assurance High
the PIDs in the German Wallet implementation and their use as an electronic identity shall be based on the German eID

Reference Design Proposals¶

This section lays out different design options for implementing the remote (i.e., online) issuance and presentation using the German eID system.

Note: The current document aims at covering the potential solution space based on existing solutions in Germany and the EU as well as international developments in order to provide the basis for a comprehensive analysis and discussion. The objective is to find the best solution based on an assessment from different angles, such as security, privacy, complexity, potential user reach, and user experience. The number of options will be reduced in the course of that process.

The PID Provider obtains the EUDIW user's identity data using the German eID system. It then creates a PID credential in either ISO mdoc or SD-JWT VC format. From a high level view, two options exist to transmit a PID credential: The PID Provider either provides the credential directly (Server Retrieval) or indirectly (Device Retrieval) to the Relying Party that requested for the PID as shown in Figure 2. A Relying Party trusts the PID data if it trusts the PID Provider and its issuance and presentation process.

Depicting data flows and trust relationships.

Figure 2: Architecture overview.

The Server Retrieval options are not pursued for the German EUDI Wallet architecture as this would allow the PID provider to monitor where the user submits their PID and therefore contradict essential privacy requirements.

The possible architecture designs for Device Retrieval are further distinguished by the following factors:

Trust Anchor (Unforgeability): Two mechanisms may be used to cryptographically ensure the authenticity and integrity of the PID:
- Authenticated Channel - The data is protected with an HMAC and may be encrypted using a symmetric secret specific to a certain transaction with a Relying Party. The secret is determined through key agreement (ECDH) based on an ephemeral key of the Relying Party. The secure channel serves as replay protection and binds the data to a specific transaction. The approach requires the authoritative source to create the secure channel or a party that has a similar security and trust level (e.g., a trusted applet residing in a certified Secure Element). This approach is used by the German eID system.
- Signature - The data is protected by a signature created by the PID-Provider. The PID is bound to a certain key managed by the Wallet. This key is used to sign a presentation of the PID to the RP, which serves as cloning protection and binds the presentation to a certain transaction. Since the data is signed, it provides non-repudiation but eliminates proper plausible deniability for the user to an uninvolved party. This approach is used today, e.g., for QES.
Trust Anchor (User Binding): Different mechanisms may be used to securely bind the PID to the user as identity holder:
- eID-Card - Secure authentication is based on the German eID-Card
- Cloud Support - Secure authentication is based on a trust anchor in the cloud.
- SE Smartphone - Secure authentication is based on a SE within the smartphone

Note 1: All architecture designs allow for the request and presentation of PID or one or more (Q)EAAs or both in one session by the Relying Party and the Wallet.

All architecture designs allow for the following technical standards:

OpenID for Verifiable Credentials protocol family
- OpenID4VCI for Issuance of the PID
- OpenID4VP for Presentation of the PID and optionally other (Q)EAAs
PID Credential Formats
- IETF SD-JWT VC
- ISO mdoc (as defined in ISO 18013-5)

Additionally, an alternative implementation based on the RestAPI protocol according to ISO/IEC 23220-4 is shown for Option B below.

All PID options allow the issuance of either SD-JWT VC or ISO mdoc or even a combination of both. For the sake of brevity, not all PID option flows include both credential format options.

Based on these architecture choices, Figure 3 gives an overview of the solution space.

Overview solution options

Figure 3: Overview of solution options.

The different solution options are explained in the following and contain a technical description including the cryptographic assets and sequence diagrams. Additionally, each option is linked to a user journey that shows the various flows from a user perspective as lo-fi wireframe screen sequences. All screens of the User Journey are labeled with a specific name. Within the associated sequence diagram, green hexagonal markers labeled "Screen: screen_name" are placed to indicate the corresponding screen in that sequence. The Lo-fi wireframes primarily serve to illustrate the architecture flow from the UX/UI perspective and to show how an implementation could look from the UX/UI perspective. However, it should be kept in mind that the actual realization and implementation of the UX/UI is the responsibility of the wallet providers and the relying parties.

PID Provider Authenticated Channel¶

Authenticated Channel with eID-Card (B) - The authentication of the identity holder for any presentation of the PID is based on the German eID. The PID is created by the PID Provider on demand and presented via the Wallet to the RP within a MAC-authenticated secure channel.

User Journey: PID Presentation - Authenticated Channel - eID Card
Technical Description and Sequence Diagrams
Alternative implementation using the RestAPI protocol according to ISO/IEC 23220-4: Technical Description and Sequence Diagrams

Authenticated Channel with Cloud Support (B') - A "seed credential" is derived by the PID-Provider (e.g., using the German eID) and stored in the Wallet signed by the PID Provider for a limited time-period. The PID is created by the PID Provider out of the seed credential on demand and presented via the Wallet to the RP within a MAC-authenticated secure channel. Therefore, the holder authenticates to the PID-Provider based on the security functions of the smartphone and a secure evaluation of the PIN by the PID-Provider in the cloud.

Authenticated Channel with SE Smartphone (D) - The PID data is issued by the PID Provider into a (Java Card) Applet of the Wallet Provider in the Secure Element on the user's device (e.g., using the "Online-Ausweisfunktion"). The PID authorizes a Wallet-controlled key to present the PID to RPs through a MAC-authenticated secure channel. Therefore, the holder authenticates to the Secure Element based on the secure evaluation of authentication by the Secure Element of the smartphone.

PID Provider Signed Credential¶

Options for PID Provider signed credentials leverage the concept of a Wallet Secure Cryptographic Device (WSCD). This is an abstraction that can be implemented in many ways, including secure elements residing in a mobile device (SE), external tokens (such as eID cards or FIDO authenticators), an applet on a eUICC, remote services (based on a remote HSM), and combinations of those options.

Signed Credential with eID-Card (C'') - The authentication of the identity holder for any presentation of the PID is based on the "Online-Ausweisfunktion". The PID is created by the PID Provider on demand as a PID Provider signed credential and presented via the Wallet to the RP.

User Journey: PID Presentation - TBD
Technical Description and Sequence Diagrams

Signed Credential with Cloud Support (C') - A credential is derived by the PID-Provider (e.g. using the "Online-Ausweisfunktion") and stored in the Wallet as a credential signed by the PID Provider. The cloud/remote HSM acts as a WSCD that controls the keys used for presentation of the PID. The Wallet presents the Issuer-Signed PID credential to the RP and the key binding is performed by the cloud HSM. Therefore, the user authenticates to the cloud-based key store based on the security functions of the smartphone and a secure evaluation of the PIN by the cloud based key store.

Signed Credential with SE Smartphone (C) - A credential is derived by the PID-Provider (e.g., using the "Online-Ausweisfunktion") and stored in the Wallet as a credential signed by the PID Provider. The Secure Element acts as a WSCD that controls the keys used for presentation of the PID. The Wallet presents the Issuer-Signed PID credential to the RP and the key binding is performed by the Secure Element. Therefore, the user authenticates to the secure key store of the smartphone based on the secure evaluation of authentication by security functions of the smartphone.

User Journey: PID Issuance - Issuer Signed
User Journey: PID Presentation - Issuer Signed
General Technical Description of Signature-based Credentials (within the general description, the WSCD is realized with a SE in the smartphone and user authentication is realized with a PIN evaluated in the SE in the smartphone)

Preliminary Assessment and Comparison of PID Design Options¶

The architectural options presented do not claim to represent a perfect solution for all problems in the environment of an EUDI wallet. All options have their own advantages and disadvantages in security, privacy and usability and scalability. Some options are more suitable for simple (Q)EAAs than others, but in principle there are additional legal requirements for the use and consideration of the PID that make a different or more complex solution necessary for the identification/authentication on LoA high. In the current (early) phase of the project, the options are therefore to present a basis for discussion and further analysis, including the development of new alternatives. A complete assessment (based on BSI-TR 03107) of the solutions regarding the level of assurance, will be possible when the design/architecture is finalized. For now, several assumptions are made e.g. regarding a proper implementation and a certification of the used hardware etc.

	Authenticated Channel			Signed Credential
	eID-Card	Cloud Support	SE Smartphone	Cloud Support	SE Smartphone
	B	B'	D	C'	C
Privacy Considerations
Unobservability	The PID provider is involved in the presentation and can learn the time and frequency of the presentation as well as the attriputes presented. The Wallet provider is not involved in the presentation.	The PID provider is involved in the presentation and can learn the timing and frequency of presentations. The Wallet provider is not involved in the presentation.	PID provider and Wallet provider are not involved in the presentation.	PID provider and Wallet provider are not involved in the presentation. The cloud key store provider cannot assert whether the usage of a key belongs to a PID presentation.	PID provider and Wallet provider are not involved in the presentation.
Unlinkability	RP: An RP cannot assign two presentations to the same user (ephemeral keys). RP+RP: see RP. PP+RP: Could assign issuance and presentation transactions to the same user if PP logs PID presentation keys.	RP: An RP cannot assign two presentations to the same user (ephemeral keys). RP+RP: see RP. PP+RP: Could assign issuance and presentation transactions to the same user if PP logs PID presentation keys.	RP: An RP cannot assign two presentations to the same user (ephemeral keys). RP+RP: see RP. PP+RP: Could assign issuance and presentation transactions to the same user if PP logs PID presentation keys (could be prevented if group keys are set for multiple users).	RP: An RP cannot assign two presentations to the same user (ephemeral keys). RP+RP: see RP. PP+RP: Could assign issuance and presentation transactions to the same user if PP logs PID presentation keys.	RP: An RP cannot assign two presentations to the same user (ephemeral keys). RP+RP: see RP. PP+RP: Could assign issuance and presentation transactions to the same user if PP logs PID presentation keys.
Selective Disclosure	Achieved through logic in SE of eID-Card.	Realized with salted hashes.	Achieved through logic in SE of smartphone.	Realized with salted hashes.	Realized with salted hashes.
Repudiation	The authenticity of the PID cannot be proven to third parties. PID is not signed. Ephemeral keys are used for authenticated channel.	The authenticity of the PID cannot be proven to third parties. PID is not signed. Ephemeral keys are used for authenticated channel.	The authenticity of the PID cannot be proven to third parties. PID is not signed. Ephemeral keys are used for authenticated channel.	The authenticity of the PID can be proven to third parties. PID is signed.	The authenticity of the PID can be proven to third parties. PID is signed.
Security Considerations
LoA	By leveraging the security functionality of the eID-Card and PID provider, PID retrieval could be sufficient for LoA high.	TBD	By having most security functionality within secure hardware, this option may be able to achieve LoA high, depending on the degree to which the secure hardware can be protected.	TBD	By having most security functionality within secure hardware, this option may be able to achieve LoA high, depending on the degree to which the secure hardware can be protected.
Unforgeability	PP authenticated channel (ECDH+HMAC)	PP authenticated channel (ECDH+HMAC)	PP authenticated channel (ECDH+HMAC)	PP signed credential	PP signed credential
Freshness	Dynamic authentication via challenge Response (OpenID4VC)	Dynamic authentication via challenge Response (OpenID4VC)	Dynamic authentication via challenge Response (OpenID4VC)	Dynamic authentication via challenge Response (OpenID4VC)	Dynamic authentication via challenge Response (OpenID4VC)
User Binding	2FA of eID-Card via knowledge (PIN, validated in SE of eID-Card) and possession (key, SE of eID-Card)	2FA via knowledge (PIN, secure cloud validation) and possession (smartphone-bound key, TEE/TRH/SE)	2FA via knowledge (PIN, validated in SE of smartphone) and possession (smartphone-bound key, SE)	2FA via knowledge (PIN, secure cloud validation) and possession (smartphone-bound key, TEE/TRH/SE)	2FA via knowledge (PIN, validated in SE of smartphone) and possession (smartphone-bound key, SE)
Usability Considerations
External token required for presentation by the user	eID-Card required	no	no	no	no
Combined presentation of PID and (Q)EAA	yes	yes	yes	yes	yes
Scalability Considerations
Minimum Device Requirements	Any NFC equipped device. Platform mechanisms (e.g., Android Key Attestation, iOS App Attestation) for wallet attestations.	Any NFC equipped device. Platform mechanisms (e.g., Android Key Attestation, iOS App Attestation) for wallet attestations.	Any NFC equipped device with programmable secure element or eUICC resistant to attack potential high. Platform mechanisms (e.g., Android Key Attestation, iOS App Attestation) for wallet attestations.	Any NFC equipped device. Platform mechanisms (e.g., Android Key Attestation, iOS App Attestation) for wallet attestations.	Any NFC equipped device with programmable secure element or eUICC or OEM key store resistant to attack potential high. Platform mechanisms (e.g., Android Key Attestation, iOS App Attestation) for wallet attestations.
Interoperability Wallet & RP	The proposed design requires additional algorithms for key agreement and message protection in the ARF (Authenticated Channel).	The proposed design requires additional algorithms for key agreement and message protection in the ARF (Authenticated Channel).	The proposed design requires additional algorithms for key agreement and message protection in the ARF (Authenticated Channel).	This option is lined up with the current ARF.	This option is lined up with the current ARF.
Offline support	No (eID-Service required)	No (cloud support required)	Yes	No (cloud support required)	Yes
Cloud service with high availability required for presentation	eID-Service for eID-Card & PID-Provider for ad hoc issuance	PID-Provider for ad hoc issuance	No	Cloud key store	No

Considerations on Performance, Availability, etc. of the individual components¶

Depending on the chosen architecture, there are a wide variety of components that all have different requirements of availability or performance and for which scalability must be considered. The following list is intended to provide a brief overview of the relevant components but is not exhaustive.

PID Provider (including eID-Server, HSM)
Wallet instance
Wallet Secure Cryptographic Device (remote or on the device)
Wallet Backend (including HSM)

Backend components might be required, which has a significant influence on the various aspects covered in this section.

Availability¶

It can be assumed that the wallet can be in different stages of use, which have different requirements for the components:

During issuance of Credentials, PID provider and the WSCD must be available. When the WSCD is not part of the Smartphone of the holder/user, the remote WSCD service must be available too.
During presentation of Credentials, the WSCD and, only in some cases, the PID provider are required. Therefore, the estimation of the scalability of the PID provider depends directly on the choice of the actual infrastructure and architecture of a wallet solution: required availability might be temporary or recurring.

The wallet provider (and its key management hardware) must be available during the onboarding of a wallet. Depending on the choice of revocation mechanism, later retrievals can be possible or necessary, which would also have an impact on the availability requirements of this component.

Scalability¶

For the scalability of the PID provider's eID service, the existing eID systems can be used. Reading the data would not be a problem, assuming the eID service has sufficient resources available.

	Options that use Secure Element on the Smartphone (D+C)	Option with on demand PID issuance (B+C'')	Options with Could Support (B'+C')
Performance	Generally speaking, background communication is only needed for the provisioning and personalization of the PID, therefore short down times for maintenance and similar events will only affect relatively few users.	The PID Provider is contacted during presentation and must therefore be available at all times and be able to withstand unforseeable load peaks.	The wallet backend is accessed during every presentation and must therefore be available at all times and be able to withstand unforeseeable load peaks.
Scalability	A lot of unknowns when it comes to provisioning and personalization scalability.	Backend communication through one or more PID providers would be scalable.	Need to consider how to scale HSM communications.

Hardware security considerations¶

The options that use a PID provider authenticated channel use signature keys to authenticate the ephemeral keys for the authenticated channel.

Option B and B' use a signature key for the authenticity of the ephemeral keys and thus also for the authenticity of the PIDs issued ad hoc. The signature key for B and B' is located, for example, in an HSM in the environment of the PID provider. If the signature key were compromised, an attacker could theoretically authenticate any PIDs. The signature key would have to be revoked. However, no PIDs would have to be revoked, as no permanently valid PIDs are issued.

Option D presumably uses a group key such as the eID card that is stored in the applet in the SE of the smartphone in the user's environment. If the group key is compromised, an attacker could theoretically authenticate any PIDs. The group key would have to be revoked. All PIDs that use the same group key would no longer work. However, it is not known which issued PIDs are affected, resulting in a complex revocation scenario.

The options that use signed credentials use a signature key for signing that is located for all options, e.g. in an HSM in the PID provider's environment.

If the signature key is compromised, an attacker could theoretically authenticate any PIDs. The PIDs already issued would have to be revoked. The impact could be reduced if the diversity of the signature keys were increased, e.g., for short-lived and long-lived signed credentials.

As there is currently no publicly available information on the breach of keys in Common Criteria certified SEs or HSMs, it can be assumed that the probability of these devices being compromised is very low. In any case, a proper certification of the secure hardware is mandatory to ensure it is tamper and duplication proof against a high attack potential. Adhering to using only certified Secure Elements from trustworthy (European) hardware manufacturers reduces the risk of compromise even further. Usage of remote/cloud HSMs would further require the security environment to be certified according to ISO 27001. The SE chip/HSM production can only be verified through third party certification, as such the security may be considered less reliable than for the smart card. Whether this "risk" can be accepted for LoA “high” has not been thoroughly evaluated yet.

Furthermore, the data authenticity during transmission from the eID card to the PID Provider during issuance is done via the German eID for all options. We are confident that using the German eID (notified for LoA “high”) raises only acceptable risks for all use-cases. Consistent testing, certification and mandatory supervision of the chip production under the Federal Ministry of the Interior ensure a very high level of reliability and trust in the German eID. In fact, there has not been any meaningful security incident to the eID card since its introduction in 2010.

Batch Credential Issuance¶

When the same Issuer-signed credential (as in PID option C) is reused for the same Relying Party or across multiple Relying Parties, it becomes possible to link these transactions and track users across different use cases. This is due to the properties of mdoc and SD-JWT credential formats using:

unique hashes for the disclosures
unique public keys for key-binding
unique PID Provider signatures
unique reference for the status

To achieve the unlinkability requirements (as described in Unlinkability), the Provider issues a batch of credential instances that all contain the same credential dataset but with different cryptographic material. This functionality is enabled by using the Credential Endpoint of the OpenID4VCI protocol. It requires the Wallet to send a number of different keys used for cryptographic binding in the Credential Request and requires the Provider to choose individual salts for the Disclosures (therefore resulting in individual signatures as well) in the Credential Response. If the Wallet utilizes the batch-issued credentials as one-time use, unlinkability for the same Relying Party and colluding Relying Parties can be achieved. If all issued credentials have been used, the Wallet should request new credential instances from the Provider, preferably using Refresh Tokens to avoid a repeated user authentication.

The optimal batch size depends on several factors:

the frequency with which the user needs to present a unique credential over time,
the user experience during the issuance process when a bigger batch size is chosen,
the wallet's capacity to manage a larger number of credentials, which may be influenced by factors such as hardware-based key storage,
the available resources that the provider has for issuing credentials in larger quantities at a specific time.
the used revocation mechanism

The Provider is able to define a limit for the maximum number of batch size to issue, but it is up to the wallet to choose the actual size of the batch. The Wallet could take into account information of the individual user's credential usage in the past.

The Provider needs to pay attention to further data in the batch-issued credentials that could lead to linkability. It must be prevented that data exists, that is unique to batch issued credentials that belong together. Data that is shared across all or a large quantity of batches can in general be kept as is.

The following recommendations are made:

Issuance, validity and expiration dates
If using timestamps with high precision the timestamps can be unique to the batch or at least unique within a small group of batches. To prevent that, the issuer should choose a lower precision, for example the start or end of the day. The exact precision to use needs to be determined by the amount of credentials issued per time period.
Status information
Depending on the mechanism used, the credential may contain an identifier or index, that links to the status information in a status list or identifier list. Each unique identifier or index must be unique, if it cannot be omitted. Indices and identifiers must be distributed randomly to prevent linkability by these.
Cryptographic material
Each credential must contain unique values for all cryptographic material, this includes cryptographic keys (especially the holder binding), signatures, nonces, salts and random values. Nonces and salts must be distributed randomly.
Unique identifiers
Depending on the format other fields may be used that could act as unique identifier for the batch if not chosen randomly. This can for example be the jti claim in an SD-JWT VC and the digest IDs in an ISO mdoc. Such values must only be equal for different credentials in a batch in negligible cases.
Changes to the issuer system
When changes are done to the issuer system, care must be taken to prevent the creation of a small subset of credentials, that share a common property. An example is that an update is introduced, that changes the size of a nonce value from 8 to 12 bytes. Immediately after the release, it is discovered, that in fact 16 bytes are needed and a new update is rolled out within ten minutes. All credentials that fall in this ten minutes frame share the 12 bytes nonce length and thus form a small subgroup. Those credentials are less protected by herd privacy than the other credentials. To identify such subgroups all information in the credential must be considered: it is not enough to prevent subgroups for each information individually but the combination of things like nonce length and rounded timestamps needs consideration.

Besides these efforts, users may be (intentionally) linked by the data that they disclose to the Relying Parties. Most German citizen are trackable by the combination of first name, last name and birth data and for certain use cases that require to identify the user, linkability is intentional. However, the underlying technology should aim to enable unlinkability, thus batch-issued credentials are recommended.

Revocation¶

Revocation of credentials is a process in which the issuer of PID or (Q)EAA declares that the credential is no longer valid. Various use cases and scenarios may require revocation:

the PID/(Q)EAA Provider wants to revoke its issued credential because the contained data is no longer valid
the Wallet Provider wants to revoke a Wallet Instance because Wallet Security Cryptographic Device (WSCD) or the Wallet Instance application is compromised or vulnerable
the user wants to revoke their Wallet Instance because they lost their smartphone
the user wants to revoke their PID
the PID Provider wants to revoke a PID because the person has died

Regarding the various PID options, only the issuer-signed variations like C or C' require revocation as the Authenticated Channel variations generate fresh credentials for every transaction.

To enable revocation within the EUDI Wallet ecosystem, the following mechanisms for revocation are considered:

Certificate Revocation Lists
Status Lists
Online Certificate Status Protocol (OCSP)
OCSP stapling

Certificate Revocation Lists¶

Certificate Revocation Lists (CRL) as defined in RFC5280 are an established revocation mechanism for X509 certificate that has been proven in productive environments for a long time. The Issuer maintains a publicly available list that contains the serial numbers of revoked certificates. Relying Parties may discover this list (e.g. as the URL is contained in the certificate) and validate whether the serial number exists in the list.

As the issuer of a certificate always delivers the complete list, he will not learn which serial number the Relying Party is interested in, thus guaranteeing the unobservability. As CRLs are currently only used for X509 certificates, it remains open to define how this mechanism is used for the PID credential formats. Additionally, CRLs have seen some scalability limitations in the Browser TLS context, and it remains open to evaluate if CRL sizes remain manageable within the eIDAS ecosystem. Usage of CRL Delta updates may be considered to increase the scalability.

Status List¶

IETF Token Status List is a new mechanism with similar properties to CRLs, which defines a status mechanism for JOSE and COSE secured Referenced Tokens. This status links to a Status List in JSON and CBOR formats that describe the individual statuses of multiple Referenced Tokens. The statuses of all Referenced Tokens are conveyed via a bit array in the Status List. Each Referenced Token is allocated an index during issuance that represents its position within this bit array. The value of the bit(s) at this index correspond to the Referenced Token's status. The Status List is provided by the issuer through a public endpoint or as a signed Status List Token in JWT or CWT.

As the issuer of a status list always delivers the complete list, he will not learn which index the Relying Party is interested in, thus guaranteeing the unobservability. Status List have shown to have better scalability properties than CRLs under most circumstances, but it remains open to evaluate if this is sufficient for the eIDAS ecosystem. Status Lists have not been widely adopted and proven in productive ecosystems yet. The Status List requires additional communication between the issuance and revocation service during the issuance.

Online Certificate Status Protocol (OCSP)¶

In the Online Certificate Status Protocol the issuer provides a service(called OSCP Responder), which the Relying Party may use to query the revocation status of a certificate in real time.

As the Relying Party provides the specific certificate serial number to the issuer, unobservability can not be achieved. As OCSP is currently only used for X509 certificates, it remains open to define how this mechanism is used for the PID credential formats. Furthermore, the system has shown to have bad scalability properties. Therefore, usage of OSCP is not recommended.

OCSP stapling¶

In the OCSP stapling the TLS certificate owner regularly queries the issuer's OCSP endpoint and "staples" the result to the response of the TLS handshake, thus the other party does not need to fetch it themselves, reducing the traffic and cost for the OCSP Responder.

OCSP stapling was introduced to tackle the scalability issues of OCSP but only with modest success. OCSP stapling is currently only defined for X509 certificates, but a proposal applying the concepts to the PID credential formats is under development. The concept has the privacy potential as the Relying Party does not fetch the revocation information itself, but it remains open whether sufficient scalability can be achieved.

Wallet revocation and WIA/WTE security assurances¶

Beside the revocation of attestations, there are reasons that necessitate to revoke the wallet itself. For example, if the backend wants to revoke the wallet, due to a security breach or similar, it needs to differentiate between the wallet solution, the wallet instance and the wallet unit. For that, indications, or "attestations" are needed to guarantee towards another entitywhether a wallet instance/unit/solution is still valid or has been revoked, as the issuer or RP has no other means to detect this.

Adopted implementing acts on Articles 5a and 5c define a "wallet unit attestation" (WUA), which refers to both the wallet instance and secure hardware (WSCD/WSCA). Corresponding to those definitions, the ARF version 1.4. specifies a "wallet instance attestation" (WIA) as well as a "wallet trust evidence" (WTE). After a first assessment, we see an advantage of keeping two separate attestations instead of just one, since it allows to also have different lifetimes and revocation mechanisms. We believe the WIA/WTE approach is compatible with the WUA. As such, we propose a wallet revocation using both WIA and WTE. We will revisit this proposal in the future, after discussions on the WUA have been finalized in the Implementing Acts.

The following security assurance for issuers and RPs shall be attested by the corresponding attestations:

WIA assures:

Trustworthiness of the wallet solution overall
Trustworthiness of the wallet instance
Trustworthiness of the device and OS
Wallet has not been revoked by the user

WTE assures:

Trustworthiness of the WSCA/WSCD managing defined cryptographic keys and their security properties
Trustworthiness of the user authentication mechanism used to authenticate to the WSCA/WSCD

Content and lifetime of the attestations may differ, depending on the chosen architecture. E.g., an architecture with a WSCD/WSCA based on a secure element in the device may not want to issue short-lived WIAs for each presentation, as it requires a callback to the backend each time.

According to implementing act on 5a (23) PID and EAA of the revised regulation (EU) 910/2014, in Art. 5 (4b), the issuer revokes the issued PID, if the WUA (here WTE) to the corresponding wallet unit they have issued the PID to, gets revoked (revocation chaining). The RP can be assured of the WTE guarantees through verifying the validity of the PID, as otherwise, if the WTE has been revoked, the PID would have been revoked as well.

To fulfill this requirement, different approaches for revocation are possible, differing e.g., in the attestations' lifetime and recipients. In the following, they are outlined for where the WUA is comprised of a WIA and WTE, attesting the components as described at the beginning of this section (Note: the ARF discussions for the WUA are not yet finalized and are subject to change):

1 Long-lived WIA and WTE: Both Wallet Attestations are long-lived, meaning that they need to be revoked actively by the Wallet Provider, upon compromise, request of the user or similar. Furthermore, both attestations are only send to the PID and Attestation Providers during issuance, but not to the RPs during presentation. In order for the RP to verify the validity of the Wallet Unit, the PID and Attestation Providers must perform "revocation chaining": meaning, they revoke their issued PID or attestations upon revocation of either the WIA or WTE by the Wallet Provider, for which the PID and Attestation Provider must frequently check their validity. During presentation, a RP "only" verifies the validity of the presented PID/attestation and can be assured of the Wallet Units' (Instance and WSCA/WSCD) validity through this. That is, as the presented attestation would be revoked if either the WIA or WTE was revoked as well. This shifts the "liability" of verifying the validity of the Wallet from the RP to the PID and Attestation Providers.
2a Short-lived WIA and long-lived WTE: The WIA is short-lived (lifetime < 24 hours) and requires no revocation. Revoking the WIA is equal to not issue them any further by the Wallet Provider. It can be issued either ad-hoc or in batch once a day. The WIA is communicated to both the PID and Attestation Providers and the RPs, upon their explicit request. A RP requesting a WIA must then verify both the presented PID/attestation(s) and the WIA. The WTE is long-lived and requires revocation by the Wallet Provider. Furthermore, the WTE is only communicated to the PID and Attestation Providers, but not the RPs. In order for the RP to verify the validity of the WSCA/WSCD managing the cryptographic keys belonging to a presented PID/attestation, as well as the authentication towards it, the PID/Attestation Providers perform revocation chaining for their issued attestations depending on the validity of the WTE only. That is, if the secure hardware is compromised, the WTE gets revoked by the Wallet Provider/RWSCD and subsequently the PID/attestations, that were issued into the WSCD attested by this WTE, get revoked by the PID/Attestation Provider.
2b Short-lived WIA and WTE: Both Wallet Attestations are short-lived (lifetime < 24 hours), meaning that they don't require revocation by the Wallet Provider. Revoking the WIA and WTE is equal to not issue them any further by the Wallet Provider. They can be issued either ad-hoc or in batch once a day. The WIA is communicated to both the Attestation Provider and the RPs, upon their explicit request. A RP requesting a WIA mut then verify both the presented PID/attestation(s) and the WIA. The WTE is only communicated to the PID/Attestation Provider during issuance. The PID/Attestation Providers verify the validity of the WSCA/WSCD, only at the moment of issuance, when verifying the validity of the WTE. Afterwards, they do not have no further obligation to link their issued PID's/attestations' validity to the validity of the WTE. During presentation, a RP verifies the presented PID/attestations validity as well as the WIA, if they requested it. However, due to the short lifetime of the WTE and no revocation chaining performed by the PID/Attestation Providers, the RP cannot verify the validity of the WTE through the presented PID's/attestations' validity. Instead, the RP "trusts" the Wallet Backend to that the WTE assurances are fulfilled through the WIA. This can be done by, e.g., only issuing a WIA (either ad-hoc or in batch) upon verifying if the WTE, attesting the WSCA/WSCD, is still valid. If not, no WIA (batch) will be issued.
3 Short-lived WIA and WTE: Similar to option 2b, both Wallet Attestations are short-lived and managed by the Wallet Provider. However, both WIA and WTE are send to both the PID/Attestation Providers and the RPs, if they request it. A party receiving the two Wallet Attestations verify both their validity directly. PID/Attestation Providers thus also do not perform any revocation chaining. Note: the WTE presented to the RP may not contain all the information as the WTE presented to the PID/Attestation Providers, as the latter may contain information about the secure hardware needed for issuance but not presentation

For options 2a, 2b and 3, Wallet Attestations that are short-lived may also be implemented as long-lived with revocation. In that case however, batch issuance is required for them as to not introduce linkability across Issuers or RPs. Furthermore, for option 2a, usage of short-lived WTEs for Attestation Providers other than the PID Provider may be used (Issuer Trust Evidence - ITE).

For those options with revocation chaining (1, 2a), it must be noted that the general requirement, which introduces the aforementioned "liability shift" to the Issuers, can only be applied to the PID. That is, as the PID Provider and (state-managed) Wallet Provider both fall under MS liability, while, after a first assessment, the German law does not allow to push/force such a requirement onto QTSPs. However, if a QTSP decides to adopt such a revocation chaining policy for their issued attestations, e.g., due to internal service requirements, they may do so. As such, option 1 may not be possible in Germany.

In order to decide which option for revocation and lifecycle to use, factors such as security, privacy, scalability, interoperability, costs, and ux should be considered. In the following, we have made a first analysis on these points (issuer specific (service) requirements and policies, e.g., QTSPs deciding to perform revocation chaining, are out of scope of this analysis):

Option 1: For this option, Issuers and RPs receive all assurances or can always verify them indirectly through the presented PID/attestation(s) (Security). Due to the long-livedness of the Wallet Attestations, the Wallet Provider has to manage and maintain the revocation and their entries (Scalability). PID and Attestation Providers need to monitor the validity of the WIA and WUA and revoke their issued PID/attestations accordingly (Scalability, Cost). Due to this, issuers may also learn when a Wallet has been revoked (Privacy). The more Providers are in the ecosystem, the higher the complexity and workload gets, and the more dependency on the active participation of the issuer, for the whole lifetime of their issued credentials, exist (Scalability). Furthermore, the eIDAS regulation has no mandate to require QTSPs to perform revocation chaining for their issued attestations, and at least in Germany this is most likely not possible (Interoperability). The revocation of the WIA or WTE would also trigger the revocation of the PID and all other attestations issued into the Users' wallets, which may not be necessary in every case (Usability).
Option 2a: While Issuers receive all assurances through the WIA and WTE, RPs must request the WIA if they need them as well (Security). Due to the short-livedness of the WIA, the Wallet Provider may get metadata about the WI through the WIA, and, if the WIA is issued ad-hoc, the Wallet Provider may infer when a Wallet is performing an issuance or presentation (Privacy), which also means regular WIA-issuance by the WP and fetching by the Wallet (Scalability, Cost). While not as bad as for option 1, the PID Provider must, and Attestation Providers may/should, monitor the WTE and revoke their issued PIDs or attestations accordingly (Scalability). The reliance on short-lived WIAs also impacts the offline-capability of the Wallet, as they need to fetch the WIA ad-hoc or in batch once a day at the Wallet Provider (Interoperability, UX).
Option 2b: Similarly to option 2a, the RP must request the WIA in order to be assured of the wallet's validity, while the issuers receive and verify this through the WIA and WTE during issuance (Security). Also similar to 2a, the Wallet Provider may get metadata about the WI or, in case of ad-hoc issued WIAs, infer when the wallet issues or presents something (Privacy). The workload is shifted from the Issuers to the Wallet Provider, as they former don't need to monitor the WIA and WTE, while the latter now has to regularly issue new WIAs and WTEs (Scalability, Cost). Furthermore, RPs now have to request and verify both the WIA and WTE, if they require it (Scalability). In the case of multiple WSCDs being used, this option does not allow to discern them effectively and may lead to revoking the whole WI, if "just" one WSCD has been revoked (Interoperability, UX). Due to regular fetching of both the WIA and WTE at the Wallet Provider, this option is also not offline-capable (UX).
Option 3: Assurances are verified through the WIA and WTE for the issuers, and for RPs if they request them (Security). As before, the Wallet Provider may get metadata about the wallet through the WIA or WTE, and, if they are issued ad-hoc, may also infer when a Wallet is issuing or presenting something (Privacy). The WTE may also not contain the same information when presented to a RP compared to when presented to an issuer, as to not provide any information about the WSCD that is not needed for the RP besides its validity information (Privacy). Similarly, regular issuance of WIAs and WTEs by the WP, and fetching by the wallet, is needed (Scalability, Cost). Furthermore, RPs have to request and verify both WIA and WTE if needed (Scalability).

Please note that for interoperability, and due to the volatile nature of the ARF, the ARF conformance may not be given for every option listed here. A review of the options, and their applicability and compliance, after ARF finalization, or at least on the parts about WUA and wallet revocation, must be performed. tbc The above options, especially those with revocation chaining (1, 2a), consider only the PID and QEAAs. For example, issuers of non-key-bound attestation such as EAAs do not require the revocation chaining, even just for the WTE, as they have lower requirements and do not possess keys generated and stored in a WSCD attested by the WTE. Sector specific requirements may also apply, but are out of scope for this analysis here. Furthermore, a future review of the options may consider (multiple) local WSCDs more in-depth, as to not require regular, and non-offline compatible, fetching of the short-lived WIAs or WTEs. It must also be discussed how to attest WTEs issued by the wallet itself for the local (or native) WSCD.

A first assessment for option C' proposes the usage of option 2a: short-lived ephemeral WIAs which are ad-hoc issued on-demand, and unique per RP (if they request the WIA, otherwise none is sent) to ensure unlinkability. Furthermore, the WTE is long-lived and only sent to the issuers. The revocation chaining may also be performed by issuers of key-bound attestations other than the PID, but are not required to by the regulation (only the PID is). The fact that option 2a may pose problems for the offline-availability is no issue for the architecture option C', as it requires regular communication to the Wallet Provider anyway. This proposal shall be revisited at a later time again.

Revocation use cases¶

As per Art. 5a (9) of the revised regulation (EU) 910/2014, the wallet shall be revoked in the following cases:

upon the explizit request of the user
where the security of the EUDIW has been compromised
upon the death of the user (or cease of activity of the legal person)

Note that the regulation requirement for revocation chaining of the PID depending on the WUA is changed here to dependency on the WTE. The reason is, that, e.g., the wallet instance, attested by the WIA, may be compromised, but would not require the revocation of the PID. The corresponding batch keys for the PID lie within the WSCD, the secure hardware attested by the WTE, and remain unaffected by the compromise of the wallet instance. Furthermore, the WIA does not have a revocation in this proposal, as they are short-lived. As such, the revocation chaining for the PID would only make sense for dependency on the WTE.

Revocation for (key-bound) attestation other than the PID may very well be regulated by issuer policies or sector-specific rulebooks, and are (mostly) outside of the scope of this approach.

Upon the death of the user, it is currently not defined how either the PID Provider or the Wallet Provider is informed of this matter. As such, the revocation for this scenario remains to be defined.

Other use cases, as well as necessary interfaces for revocation (such as, e.g., a "Wallet Provider Interface" towards the user) will be described at a later date.

Batch issuance¶

When using batch issuance to achieve verifier unlinkability, it is important for privacy reasons that the status management is using unique identifiers for each credential in the batch:

status list: each credential needs a unique index in the status list. The indices must be distributed randomly.
CRL: each credential needs a unique serial number. This serial number must be distributed randomly.

When updating the status list and the CRL object that are publicly available,the issuer should group the revocation of multiple batches into one update to avoid linkability of the individual credentials.

Credential Format mapping¶

For the PID and (Q)EAA credentials, the following mapping to the revocation mechanisms is proposed:

SD-JWT VC: Token Status List
mdoc: CRL

Online-Offline Scenarios¶

When the Relying Party is online, it will fetch the CRL and the Status List from the issuer's endpoint (or from a status provider).

When the Relying Party is offline, it will use a cached version of the CRL or the Status List with the risk of being outdated. A mechanism to pass the CRL or the Status List to the Relying Party via the OID4VP response with a trust chain and where the Relying Party only needs the root of trust is not defined yet to support fully offline scenarios.

Cross-Device PID Presentation¶

The PID Design Options presented in this document cover the transmission of the PID on the same device only, meaning the RP and the Wallet shall reside on the same device.

PID scenarios across devices are not directly supported as they cannot be secured to a Level of Assurance High. Applications wishing to support cross-device presentations may implement a session-transfer based solution instead: The application needs to transfer the user's session to the device where the Wallet is installed (e.g., by displaying a QR code that is then scanned on the second device), conduct a same-device PID presentation, and transfer the result back via the application's session backend. Since there is usually no authenticated channel for cross-device session transfer, fundamental security issues may arise, for example, when QR codes are replayed in phishing attacks. The exact implementation of cross-device session transfer flows, the security considerations, and appropriate mitigations are out of scope of this document.

Repudiation¶

Data deniability in identification scenarios can be technically achieved through several conceivable approaches and cryptographic primitives. A prominent example is the German eID solution, where an ephemeral but authenticated end-to-end channel between eID card and Relying Party is established, which is then used to transmit the PID in an unauthenticated way. The Relying Party is able to gain certainty about the card user's PID through the authenticity of the channel, but is not able to prove that to a third party after the channel has been closed. Thus, the user is able to plausibly deny the authenticity of his PID to some third party.

Note: Technically, a Relying Party trusts the PID issuer and thus any eID card with attested key material on its chip, which is used to compute a DH shared secret for the establishment of an E2E channel. Therefore, it can also consider the transmitted PID to be correct and authentic, but does not keep a proof for this.

For establishing user deniability, PID may be protected by a MAC which was generated with a symmetric secret key. In this case, PID authenticity can only be verified by entities who share the secret key---usually just the two entities involved in an identification. A third party not in possession of this key cannot distinguish the MAC from randomness, giving the user deniability about their presentation of the PID credential.

The use of digital signatures (for both, identification or PID) ensures PID integrity and authenticity, but generally obstructs any kind of deniability due to their “non-repudiation” property. A PID fragment of an identification transaction that has been equipped with a digital signature can be regarded as an officially certified copy, which allows to be cryptographically verifiable verified by everyone in possession of the respective issuer’s public key. This holds for an indefinite amount of time after the identification process. A quite unconventional approach would be to regularly publish the respective signature keys (including appropriate key management), but is at most conceivable for short-lived credentials.

PID Provider Implementation Considerations¶

PID Providers may be part of the Wallet solution or there can be a central PID Provider (then also called PID Issuer) used by all German EUDI Wallets to obtain PIDs.

If the PID Provider is part of the Wallet solution, the way PID Provider and Wallet establish trust and communicate with each other is at the discretion of the Wallet Provider.

If there is a PID Issuer, the communication protocol used for PID issuance and the way trust is established needs to be standardized.

The PID Provider is a backend service that translates from German national eID scheme into eIDAS 2.0 scheme by either issuing a PID in mdoc format or an SD-JWT VC format in accordance to the selected transport protocol while keeping eIDAS LoA High. The Wallet receives the data from the PID Provider and responds to the Relying Party.

One main component of the PID Provider is an eID-Server according to BSI TR-03130 that manages an authorization certificate with authorization bits set according to PID specification of eIDAS 2.0. The eID-Client reads the identity data from the German eID Card or Smart-eID, sends it to the eID-Server that validates the data.

The second main component of the PID Provider (for Options B and C) is a service that creates the mdoc or SD-JWT format. This includes the creation of a digital signature or MAC over the identity data read by the eID-Server. The signature or MAC is recognized as the PID attestation under eIDAS by Relying Parties and must fulfill eIDAS level high. Hence, the respective key material and access to the key material must be stored and managed in a way to resist attackers with high attack potential.

PID Provider Trust Management¶

Relying Parties must be able to establish trust in a PID. Hence, the respective PKI must be made available to the Relying Parties, for example, through Trusted lists (specifically for PID Providers).

PID Contents¶

PIDs can be issued in two formats, mdoc and SD-JWT VC.

For SD-JWT VC, the SD-JWT VC DM proposal is to be used. A type hierarchy compliant with the SD-JWT VC DM proposal needs to be defined consisting of a base type for EU PIDs and derived types for national PIDs. The base type would define a minimal dataset (e.g., given name, family name, date of birth) plus define data fields that are common to a number of national PID types (e.g., address, nationalities, gender, middle name, birth family name, etc.).

The derived types would define the specific data fields for each national PID type; in particular, national types would define which data fields out of those in the base type are generally available and add specific national data fields.

For German national PIDs, the data can be obtained from an ID card, a residence permit, or an eID card for EU citizens. The data available is defined in BSI TR-03127. Under the assumption that data fields in the base type would be structured and defined similar to those in OpenID Connect Core and OpenID eKYC Identity Assurance, a German national PID could be designed as follows:

{
    ## Base data (SD-JWT VC DM)
    "vct": "https://example.bmi.bund.de/credential/pid/1.0",  # metadata would define this as an extension of the base type, e.g., https://example.eudi.eu/credential/pid/1.0
    "vct#integrity": "sha256-jo8433ot48....utul8ura33",

    ## Base dataset that always needs to be present

    "given_name": "Erika",             # from base type, minimal dataset, may be empty
    "family_name": "Mustermann",       # from base type, minimal dataset, may be empty
    "birthdate": "1963-08-12",         # from base type, minimal dataset, may be partial date

    ## Additional data

    "source_document_type": "id_card",  # not in base type, can also be "residence_permit" or "eu_citizen_eid_card"

    "birth_family_name": "Gabler",      # from base type

    "place_of_birth": {                 # from base type
        "locality": "Berlin",
        "country": "DE"
    },

    "also_known_as": "Schwester Agnes", # from base type

    ## data available in certain situations

    "address": {                        # from base type, available for ID card and eID card for EU citizens only
        "street_address": "Heidestraße 17",
        "locality": "Köln",
        "postal_code": "51147",
        "country": "DE"
    },

    "nationalities": [                  # from base type, not available for eID cards issued before Nov. 2019
        "DE"
    ],

    "gender": "female",                 # available for residence permit only

    ## Derived claims
    "age_equal_or_over": {              # from base type
        "12": true,
        "14": true,
        "16": true,
        "18": true,
        "21": true,
        "65": false
    },

    # key binding (SD-JWT VC DM)
    "cnf": {
        "jwk": {
            "kty": "EC",
            "crv": "P-256",
            "x": "52aDI_ur05n1f_p3jiYGUU82oKZr3m4LsAErM536crQ",
            "y": "ckhZ-KQ5aXNL91R8Eufg1aOf8Z5pZJnIvuCzNGfdnzo"
        }
    },

    ## Mandatory metadata as defined by PID Rule Book v1.0.0 section 2.4

    "iat": 1712231700,
    "exp": 1806839700

}

All claims except vct, vct#integrity, cnf and the claims listed under metadata would be issued as selectively disclosable claims.

The additional claims iat and exp would define the lifetime of the PID. In Options B, B' and D, this would be a short time frame, while in Options C and C', the PID could be valid for a longer time frame.

Alternatively, multiple types could be used to distinguish between the different source document types. This would allow for a more fine-grained specification of available data fields. For example, a type hierarchy similar to the following could be created:

Base Type: https://example.eudi.eu/credential/pid/1.0
- German Base Type: https://example.bmi.bund.de/credential/pid/base/1.0
  - PID based on ID Card: https://example.bmi.bund.de/credential/pid/id-card/1.0
  - PID based on Residence Permit: https://example.bmi.bund.de/credential/pid/residence-permit/1.0
  - PID based on EU Citizen eID card: https://example.bmi.bund.de/credential/pid/eu-citizen-eid-card/1.0
- (... other national PID types)

While this design option provides more granular credential types, it has a privacy drawback: The source of the PID information is always revealed in the credential type URI and would not be selectively disclosable. If the credential is used, for example, for age verification, the Verifier learns not only the age, but also that the person presenting the credential is not a German citizen. Therefore, a single type for all national PIDs is preferred.

PIDs are issued as compact-serialized SD-JWTs.

For the mdoc format, the PID contents as defined in the ARF PID rule book are to be used.

PID SD-JWT VC Type Metadata¶

This section illustrates a first draft of the SD-JWT VC Type Metadata for the german PID. Note that the values of the fields vct, extends and extends#integrity are only placeholders and will be changed before this definition reaches a final stage.

{
  "vct": "https://example.bmi.bund.de/credential/pid/1.0",
  "name": "German Person Identification Data Credential - First Version",
  "description": "The definition of the core identification credential for all natural persons in Germany - first revision",
  "extends": "https://example.eudi.eu/credential/pid/1.0",
  "extends#integrity": "sha256-9cLlJNXN-TsMk-PmKjZ5t0WRL5ca_xGgX3c1VLmXfh-WRL5",
  "display": [
    {
      "lang": "en-US",
      "name": "German Person Identification Data Credential",
      "description": "The core identification credential for all natural persons in Germany"
    },
    {
      "lang": "de-DE",
      "name": "Deutscher Personenidentifikationsnachweis",
      "description": "Der zentrale Identifikationsnachweis für alle natürlichen Personen in Deutschland"
    }
  ],
  "claims": [
    {
      "path": [
        "vct"
      ],
      "sd": "never"
    },
    {
      "path": [
        "vct#integrity"
      ],
      "sd": "never"
    },
    {
      "path": [
        "given_name"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Vorname"
        },
        {
          "lang": "en-US",
          "label": "Given Name"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "family_name"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Nachname"
        },
        {
          "lang": "en-US",
          "label": "Last Name"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "birthdate"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Geburtsdatum"
        },
        {
          "lang": "en-US",
          "label": "Birthdate"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "source_document_type"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Quelldokumenttyp",
          "description": "Der Typ der Quelle des Dokumentes, beispielweise der Personalausweis oder der Aufenthaltstitel"
        },
        {
          "lang": "en-US",
          "label": "Source Document Type",
          "description": "The type of the source of the document, for example the national identity card or the residence title"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "address"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Adresse"
        },
        {
          "lang": "en-US",
          "label": "Address"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "address",
        "street_address"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Straße"
        },
        {
          "lang": "en-US",
          "label": "Street Address"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "address",
        "locality"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ort"
        },
        {
          "lang": "en-US",
          "label": "Locality"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "address",
        "postal_code"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Postleitzahl"
        },
        {
          "lang": "en-US",
          "label": "Postal Code"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "address",
        "country"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Land"
        },
        {
          "lang": "en-US",
          "label": "Country"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "nationalities"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Staatsangehörigkeiten"
        },
        {
          "lang": "en-US",
          "label": "Nationalities"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "gender"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Geschlecht"
        },
        {
          "lang": "en-US",
          "label": "Gender"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "birth_family_name"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Geburtsname"
        },
        {
          "lang": "en-US",
          "label": "Family Name at Birth"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "place_of_birth"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Geburtsort"
        },
        {
          "lang": "en-US",
          "label": "Place of Birth"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "place_of_birth",
        "locality"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Geburtsort"
        },
        {
          "lang": "en-US",
          "label": "Place of Birth"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "place_of_birth",
        "locality"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ort"
        },
        {
          "lang": "en-US",
          "label": "Locality"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "place_of_birth",
        "country"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Land"
        },
        {
          "lang": "en-US",
          "label": "Country"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "also_known_as"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ordens- oder Künstlername"
        },
        {
          "lang": "en-US",
          "label": "Religious Name or Pseudonym"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Altersbestätigung"
        },
        {
          "lang": "en-US",
          "label": "Age Verification"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "12"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 12"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 12"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "14"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 14"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 14"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "16"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 16"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 16"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "18"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 18"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 18"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "21"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 21"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 21"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "age_equal_or_over",
        "65"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Mindestalter 65"
        },
        {
          "lang": "en-US",
          "label": "Minimum Age 65"
        }
      ],
      "sd": "always"
    },
    {
      "path": [
        "cnf"
      ],
      "sd": "never"
    },
    {
      "path": [
        "iat"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ausstellungsdatum"
        },
        {
          "lang": "en-US",
          "label": "Issuing Date"
        }
      ],
      "sd": "never"
    },
    {
      "path": [
        "exp"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ablaufdatum"
        },
        {
          "lang": "en-US",
          "label": "Expiry Date"
        }
      ],
      "sd": "never"
    },
    {
      "path": [
        "issuing_authority"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ausstellende Behörde"
        },
        {
          "lang": "en-US",
          "label": "Issuing Authority"
        }
      ],
      "sd": "never"
    },
    {
      "path": [
        "issuing_country"
      ],
      "display": [
        {
          "lang": "de-DE",
          "label": "Ausstellungsland"
        },
        {
          "lang": "en-US",
          "label": "Issuing Country"
        }
      ],
      "sd": "never"
    }
  ],
  "schema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "title": "German Person Identification Data VCT Schema",
    "description": "The JSON schema that defines the German Person Identification Data VCT",
    "type": "object",
    "properties": {
      "vct": {
        "type": "string"
      },
      "vct#integrity": {
        "type": "string"
      },
      "given_name": {
        "type": "string"
      },
      "family_name": {
        "type": "string"
      },
      "birthdate": {
        "type": "string",
        "format": "date"
      },
      "source_document_type": {
        "type": "string"
      },
      "address": {
        "type": "object",
        "properties": {
          "street_address": {
            "type": "string"
          },
          "locality": {
            "type": "string"
          },
          "postal_code": {
            "type": "string"
          },
          "country": {
            "type": "string"
          }
        },
        "minProperties": 1
      },
      "nationalities": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "minItems": 1,
        "uniqueItems": true
      },
      "gender": {
        "type": "string"
      },
      "birth_family_name": {
        "type": "string"
      },
      "place_of_birth": {
        "type": "object",
        "properties": {
          "locality": {
            "type": "string"
          },
          "country": {
            "type": "string"
          }
        },
        "minProperties": 1
      },
      "also_known_as": {
        "type": "string"
      },
      "age_equal_or_over": {
        "type": "object",
        "properties": {
          "12": {
            "type": "boolean"
          },
          "14": {
            "type": "boolean"
          },
          "16": {
            "type": "boolean"
          },
          "18": {
            "type": "boolean"
          },
          "21": {
            "type": "boolean"
          },
          "65": {
            "type": "boolean"
          }
        },
        "minProperties": 1
      },
      "cnf": {
        "type": "object"
      },
      "iat": {
        "type": "number"
      },
      "exp": {
        "type": "number"
      },
      "issuing_authority": {
        "type": "string"
      },
      "issuing_country": {
        "type": "string"
      }
    },
    "required": [
      "vct",
      "source_document_type",
      "cnf",
      "iat",
      "exp",
      "issuing_authority",
      "issuing_country"
    ]
  }
}