The European Digital Identity Wallet
Home Page: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
License: Other
As an EUDI Wallet user, I want to access public and private online services where identification and authentication is needed, and all the necessary personal information is presented in a secure and privacy-oriented manner so that I can conveniently and safely use these services.
User: EUDI Wallet user
Goal: Access public and private online services securely and with respect for privacy
Reason: Convenient and safe access to services requiring identification
As a busy working parent, I want to be able to shop for groceries online and have them delivered to my home so that I can save time and conveniently manage my household shopping.
User: Busy working parent
Goal: Shop for groceries online and have them delivered to the home
Reason: Save time and conveniently manage household shopping
The following scenarios shall be covered.
Scenario 1: Browsing and searching for groceries
The website or app displays a clear and organized layout of product categories.
The search bar and filter options function properly and return accurate results based on user input.
Scenario 2: Adding items to the shopping cart
The product detail page contains accurate and relevant information about the item.
Users can easily select the desired quantity and add the item to the shopping cart with a single click.
Scenario 3: Reviewing the shopping cart
The shopping cart displays a comprehensive list of items, including quantities, individual prices, and the total cost.
Users can effortlessly remove or adjust the quantity of items in the cart.
Scenario 4: Checking out and selecting delivery options
The checkout process is simple, allowing users to select a delivery date and time slot.
Users can enter or confirm their delivery address and contact information without difficulty.
A variety of payment methods are available, and users can securely input their payment details.
Scenario 5: Receiving the groceries at home
Groceries are delivered within the selected time slot, securely packaged and in good condition.
Users can provide feedback on the delivery experience through the website or app.
The user story will be considered complete when all acceptance criteria are met, ensuring a smooth and efficient online grocery shopping and home delivery experience for the busy working parent.
Tasks
Section 8.1 refers to the code.europa.eu as the place where the ARF is maintained.
The EC finally decided to move the publication and the maintenance of the ARF and its backlog to GitHub:
Improve the "Readme" by providing links to the automatic HTML and DOCX builds for the text in the main branch.
Generated assets
In addition to the authoritative versions note that non-authoritative builds of the main branch are automatically created and made available as Github pages. You can access these builds in both HTML and DOCX formats using the following links:
- HTML: https://eu-digital-identity-wallet.github.io/architecture-and-reference-framework/arf.html.docx
- DOCX: https://eu-digital-identity-wallet.github.io/architecture-and-reference-framework/arf.html.docx
Please note that these builds are generated from the latest version of the text in the main branch, but may not be completely accurate or finalized
Context: This suggestion is in the "Definitions" section. It concerns the unclear status of an authoritative entity and the necessity/content of historical status.
Issue: The status of an authoritative entity is not clearly defined, and it is unclear whether historical status is necessary or what it should contain.
Proposal: A detailed explanation of possible statuses for authoritative entities, including the necessity and content of historical status, is needed.
.docx and use it for style.Context: This recommendation is related to the "Definitions" section and addresses the issue of clarity around the business model, payment mechanism, and privacy-preserving counting for QTSP services.
Issue: The document lacks clarity on the business model, payment mechanism, and privacy-preserving counting for QTSP services.
Proposal: An intermediation role should be introduced in some cases (e.g., remote signature), while preserving privacy and security requirements. The document should detail where and when this intermediation role is necessary.
Context: The suggestion concerns the "Trusted List Providers" section. Specifically, it addresses the unclear implementation details of "Catalogs of attributes and schemes".
Issue: The document does not provide clear implementation details of "Catalogs of attributes and schemes".
Proposal: Catalogs should contain Trust Marks, supported attributes, supported algorithms, and all required properties related to a subject to attest its reliability and compliance with the eIDAS regulation.
Context: The suggestion is for the "PID and (Q)EAA Lifecycles" section. The query is whether the "suspension" state should also be considered.
Issue: Currently, the document does not mention or consider the state of "suspension".
Proposal: Some use case scenarios might benefit from having the suspension or temporary revocation. For instance, the mDL scenario should be considered in this context.
Incorporate the ARF text additions as per
v1.2.0The markdown document reflects the v1.2.0 draft Word document
The following scenarios shall be covered.
Sequence diagrams offer a simple view of processes with actors and messages ordered in time.
The syntax is standardized and quick to learn (we can be experts after 30 minutes of playing with it). Some well known development environments allows to render them when embedded as source code.
They are not as powerful as BMPN diagrams but "good enough" for 95% of tasks and much more "git friendly".
Seq. Diagrams many times serve as pseudo-code for software real implementations.
My two cents!
Context: This suggestion refers to the "Person Identification Data (PID) Providers" section of the document. The text that needs attention is "Without prejudice to the actual mechanism of how the information is provided, including whether directly or indirectly."
Issue: The phrase 'directly or indirectly' is vague and may cause confusion.
Proposal: More precise language should be used to clarify this statement and potentially provide concrete examples for each case.
Context: The suggestion is for the "EUDI Wallet Solution Lifecycle" section. The question is about the mechanisms of suspension and then un-suspension.
Issue: The mechanisms for suspension and un-suspension (or re-activation) of an EUDI Wallet Solution are not clearly defined in the document.
Proposal: A description of the suspension and un-suspension mechanisms should be added to the document.
Context: The suggestion is for the "Issuing requirements for PID" section. The issue raised is why there's a requirement related to OpenID4VCI in "Issuing requirements for (Q)EAA" but not in "Issuing requirements for PID."
Issue: OpenID4VCI is not mentioned in the requirements for issuing PID.
Proposal: Add the following requirement: PID SHOULD be issued according to the OpenID4VCI protocol.
As a EUDI Wallet user, I want to obtain, store, and present my mobile driving license using the EUDI Wallet to prove my driving rights conveniently, securely, and in compliance with the regulations of all Member States.
User: EUDI Wallet user.
Goal: Obtain, store, and present a mobile driving license with the EUDI Wallet.
Reason: Conveniently and securely prove driving rights.
The EUDI Wallet app allows users to securely store and manage the mobile driving license.
Should be defined functional specifications of the EUDI Wallet for the 'Mobile Driving License' business scenario, including:
Gathering work done by the eIDAS Working Group
Distinguishing national specifications from common specifications requiring Member States' consensus.
Outlining further details for common requirements, if needed.
Standardizing the representation of specifications and consolidating them in a single document.
Documentation: Any necessary documentation, such as service blueprints, user stories and use case Description, has been created and is up to date.
Stakeholder Approval: The completed work has been reviewed and approved by relevant stakeholders, such as product owners, projects managers and eIDAS Expert Group.
The level-2 title says: The propsed Digital Identity Regulation
It should say proposed.
Context: This suggestion refers to the "Configuration Requirements" section. The sentence "EUDI Wallet Solution [...] implement safety measures to prevent export of cryptographic secrets." is highlighted.
Issue: There are no additional references or explanations provided for this aspect.
Proposal: Adding a footnote highlighting some references or providing additional explanations would benefit the reader.
After we renamed ARF.md to arf.md several references the to ARF.md broke.
arf.mdThe conversion from .docx to .md brought unnecessary blockquote markup.
Examples:
blockquote elements and clear the markup.Context: The suggestion targets the "Definitions" section and focuses on the implementation of the Trust Model for LSPs.
Issue: The current document does not clearly describe the implementation of the Trust Model for LSPs.
Proposal: Consider adopting the ETSI Trusted Lists, including an x.509 infrastructure, potentially extended using JWT formats and REST APIs, as outlined in OIDC Federation 1.0.
Evaluate the use of the Readable-CSS for the HTML version of the ARF
https://github.com/nicokant/readable-css
Context: The suggestion is for the "EUDI Wallet Solution Lifecycle" section. The question is about how the Solution state change is reflected on the Instances.
Issue: It's unclear how the state of the Wallet Solution affects the state of all EUDI Wallet Instances.
Proposal: More information should be provided to clarify the relationship between the status of Wallet Solutions and Instances.
Context: The suggestion refers to the "Definitions" section of the document, focusing on the handling of multiple PIDs in EUDI Wallet.
Issue: It's not clear if the EUDI Wallet can store more than one PID.
Proposal: To cater to citizens with multiple nationalities, the EUDI Wallet should be able to store multiple PIDs issued by one or more PID Providers. This functionality should be optional and fully under user control.
as reported by @duviner
Currently, the OpenID4VCI reference points to the broken link:
it looks like the correct one is:
For consistency, use the same capitalization and order for the "LoA High" in the entire document. The term appears as "LoA High" and "LoA high"
Use "LoA High" everywhere.
LoA high with LoA HighThe ISO standards for mdoc https://www.iso.org/standard/79126.html seems to need to be deleted. This is a valid credential format in ARF configuration requirements (Page 35, attestation exchange protocol 4). This could be removed.
Context: Security and Privacy when using an “operational” but “non valid” EUDI Wallet
Issue: We have not identified attributes and associated use cases that do not depend on being linked to a subject (at least anonymously, meaning that the verifier / Relying Party doesn’t know who that person is, just that it is an existing, non-revoked, valid subject). Therefore, the value of a Wallet in an “operational” but “non valid” mode (meaning it is not associated to a PID yet) is unclear. The “operational” but “non valid” mode reduces security by allowing use of attributes not linked to a PID. It also results in reducing privacy by encouraging the use of alternative ways to the wallet to make the link between the subject and the attribute; we expect such alternative ways outside of the wallet to reduce the level of privacy of the interaction. In summary we are concerned that using an EUDIW without a valid PID goes against the goals of the regulation.
Proposal: Remove the possibility of using an EUDIW without a valid PID from the ARF.
Context: The suggestion pertains to the "Logical architecture" section. Specifically, it's about the EUDI Wallet Data Storage Components table, and the difference between "attributes" and "personal data and attributes".
Issue: The distinction between "attributes" and "personal data and attributes" is unclear in the table.
Proposal: The two cells should either be merged into a single one, or additional explanatory text should be provided to distinguish them.
Context: This suggestion pertains to the "Issuing requirements for (Q)EAA" section. It questions why the current text mandates that (Q)EAA MUST be issued in accordance with one of the data model specifications, and not both.
Issue: The document specifies that only one data model specification can be used for (Q)EAA issuance, which restricts flexibility.
Proposal: To allow multiple issuances of the same (Q)EAA in different formats, the wording should be modified to permit the use of both data model specifications.
Fix the links in the README
Context: The suggestion pertains to the "PID and (Q)EAA Lifecycles" section. The question is about the need to define the Revocation Model implementation.
Issue: The Revocation Model implementation is not clearly defined in the document.
Proposal: The Trust Model and Revocation Model should be kept separate. More detailed information on the Revocation Model should be included.
I'm sorry if this isn't the correct venue or I'm getting ahead of myself, but I'd like to know what the current status of the PID attribute data model is?
The PID attributes in question are listed under section 5.1.1.1, but like many things in the current version of the ARF, they are described at a high level. But I've also noticed that Google identity-credential library already has the EU PID mdoc defined (added in PR openwallet-foundation-labs/identity-credential#164). Is this something they've just come up with on their own or are there any official drafts of the SD-JWT/VCDM or mdoc presentations available somewhere?
This is more of a question than a user story. Currently, the ARF doesn't address Organisational wallet.
the id="fnref1" is used for
Line 236
<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>Line 1439
<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>The problem is created by padodc due to
In an earlier draft passkeys was considered one of the key technologies. References appear to have been removed.
What is the reasoning behind this change? The technology has very high potential wrt privacy and security.
In general it would be nice to see the considerations made be included as an appendix to the ARF as that provides more context for the community and ensures that this process becomes (and remains) transparant.
Context: This suggestion pertains to the "Definitions" section of the document. It highlights a problem regarding the unclear definition and verification of a 'legal person' within the EUDI Wallet context.
Issue: The current definition and verification method for a 'legal person' is unclear, causing potential confusion and misinterpretation.
Proposal: It's suggested to adopt the approach defined in the draft OpenID specification, "OpenID Connect Authority claims extension". Although this specification only covers JSON Payload and is still a draft, its schema could potentially be ported to mDoc for seamless integration.
Incorporate into the ARF text the additions as per
v1.1.0The markdown document reflects the v1.1.0 draft Word document
Context: The suggestion pertains to the "Logical architecture" section. The phrase "Re-use of backend systems. Re-use of decentralized identity infrastructure." is highlighted.
Issue: It's unclear how the re-use of existing systems is evaluated as compliant to EUDI ARF.
Proposal: More explanation about the term 're-use' and how compliance is determined is needed.
The current authoritative version is tagged as realease/tag in this repository.
The link in the above sentence points to the wrong target. It should change to
Context: This recommendation pertains to the "Qualified and Non-Qualified Electronic Attestation of Attributes Schema Providers" section. The suggestion focuses on defining the term "(Q)EAA Schema Providers."
Issue: Currently, (Q)EAA Schema Providers is not a defined term within the document.
Proposal: A comprehensive definition of (Q)EAA Schema Providers should be added to this section.
Context: This suggestion is for the "Qualified and Non-Qualified Electronic Attestation of Attributes Schema Providers" section. The issue at hand is whether there is a need to define PID Schema Provider.
Issue: It's unclear whether the PID Schema Provider is missing or unnecessary within the document.
Proposal: A definition of PID Schema Provider should be added, or, if it's not required, a clear explanation should be provided.
Context: The suggestion pertains to the "EUDI Wallet Instance Lifecycle" section. The question is about the meaning of "activated".
Issue: It's unclear what the operations involved in "activating" a wallet are after installation.
Proposal: A description of the operations that must be performed by the user to activate the wallet after installation should be added to the document.
Context: Security of a pre-provisioned PID
Issue: In the ARF, there is a mention of use of a pre-provisioned PID (§4.2.1 in [1]),). We wonder how a high level of security can be achieved in this case.
Proposal: To clarify how a high level of security is achieved when there is a pre-provisioned PID in the EUDI.
Will a copy of the MDL spec be included in the ARF? It is currently behind a paywall.
The specification for OIDC (and sub-variants) are available without a paywall.
I also miss analysis of rights: what is the situation regards patent rights / other encumbrances wrt the core technology choices?
Context: The suggestion is for the "Logical architecture" section. The issue is related to the "Figure 6: EUDI Wallet configurations conceptual model" where RP-1 and RP-3 are mentioned.
Issue: It's unclear what the role and nature of RP-1 and RP-3 are in the model.
Proposal: A legend or an explanation describing RP-1 and RP-3 should be added to the figure.
https://www.w3.org/TR/html-aria/#docconformance-deprecated
The doc-biblioentry and doc-endnote roles are marked for deprecation in Digital Publishing WAI-ARIA Module 1.1, as they are not valid children for an element with an implicit or explicit role of list. Authors can use standard list and child li elements without the need for these roles.
li elementsIn Section 1.1 the "European Commission adopted a Recommendation 1 referees to the footnote 1:
COMMISSION RECOMMENDATION (EU) C(2021) 3968 final of 3 June 2021 on a common Union Toolbox for a coordinated approach towards a European Digital Identity Framework, OJ L 210/51, 14.6.2021 ↩
In the "Table 1: Definitions" an HTML hard coded note comes with an id that conflict with those defined in markdown
“OASIS Trust,” [Online]. Available: http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html.[↩︎](https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework/blob/main/ARF.md#fnref1)
<li id="fn1"><p>“OASIS Trust,” [Online]. Available:The id fn1 is used by the markup pandoc generates and conflicts. As a result, in the generated HTML file, Section 1.1 links to the "OASIS trust" note instead of the proper one.
ID for the hard-coded elementContext: Guaranteed privacy of the EU citizens is a major concern for EC. The comments is related to privacy and request to update ARF to ensure EU citizen privacy when using the EU ID Wallet.
Issue: There is no mechanism in ISO mDL that ensure full privacy. This standard is not sufficient to ensure unlinkability and as such Data Minimization. SD-JWT doesn’t manage unlinkability or ZKP (zero-knowledge proof).
These 2 protocols do NOT allow proper data minimization and therefore should be replaced by the necessary tools and protocols enforcing unlinkability and data minimization.
Proposition: To ensure Privacy, Data Minimization that includes Selective Disclosure and Unlinkability shall be added in the ARF. We propose to add the definition of Data Minimization in the ARF and to add requirements on anonymization for PID and (Q)EEA. A section dedicated to privacy is needed in the ARF as in ISO/IEC 23220-1, section 5.2. This paragraph shall define Unlinkability and Data Minimization and requirements related to privacy
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.