https://ssimeetup.org/introducing-ssi-eidas-legal-report-ignacio-alamillo-webinar-55/
The European Commission developed the SSI (Self-Sovereign Identity) eIDAS bridge, an ISA2 funded initiative, to promote eIDAS as a trust framework for the SSI ecosystem. It assists a VC (Verifiable Credential) issuer in the signing process, and helps the verifier to automate the identification of the organization behind the issuer’s DID (Decentralized Identifier). Simply by “crossing” the eIDAS Bridge, a Verifiable Credential can be proven trustworthy in the EU. Ignacio Alamillo will present at this SSI Meetup webinar the insights gained from this report.
In the context of the eIDAS bridge project, we performed an analysis on how eIDAS can legally support digital identity and trustworthy DLT-based transactions in the Digital Single Market, and this is reflected in the SSI eIDAS legal report, available at this link. The objective of this report is to evaluate the potential legal issues that are important to an SSI solution and make some recommendations to be used as policy input for the eIDAS 2020 review. The report outlines short-term objectives, where changes in the Regulation would not be necessary, but also mid to long-term scenarios requiring major changes in the Regulation to comply with the SSI design principles.
The different scenarios described in the report are aligned with the proposed architectural and procedural considerations designed in the SSI eIDAS Bridge project and the European Self Sovereign Identity Framework.
Magic exist by Marta Loveguard - presentation.pptx
Introducing the SSI eIDAS Legal Report – Ignacio Alamillo
1. Introducing the SSI eIDAS Legal Report
DR. IGNACIO ALAMILLO DOMINGO
SSIMEETUP
May 7th
, 2020
@NachoAlamillo
CC BY-SA 4.0 SSIMeetup.org
2. 1. Empower global SSI communities
2. Open to everyone interested in SSI
3. All content is shared with CC BY SA
Alex Preukschat @SSIMeetup @AlexPreukschat
Coordinating Node SSIMeetup.org
SSIMeetup objectives
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
3. •Lawyer, Certified Information Systems Auditor, Certified Information Security Manager. +22
years of experience in public and private sector. Phd thesis on eIDAS Regulation. Researcher
at iDerTec (University of Murcia).
•Member of UNE CTN71/SC307, ISO/TC307 & CEN-CLC/JTC19.
• Co-leader of ISO/TC 307 “Trust Anchors for Decentralized Identity Management”.
• Co-editor of ISO/TC 307 TR 23249 “Overview of DLT Systems for Identity
Management”.
•EU Commission legal expert in EBSI eSSIF and EBSI eIDAS Bridge initiatives.
#WhoIAm
CC BY-SA 4.0 SSIMeetup.org
12. eIDAS types of e-signatures and e-seals
CC BY-SA 4.0 SSIMeetup.org
13. Why eIDAS Regulation in the SSI space?
• eIDAS Regulation constitutes the main electronic identification trust framework in the
European Economic Area.
• eID is a building block of the Digital Single Market, allowing the establishment of
cross-border distance electronic relations in the e-Government field.
• eIDAS may be extended to include the recognition of eIDs for private sector uses, such
as AML/CFT, online platforms, etc.
• Its technology-neutral approach could easily allow the usage of SSI systems, constituting
a real opportunity for their adoption.
• eIDAS Regulation has a strong influence in the international regulatory space, thanks
to UNCITRAL recent works.
CC BY-SA 4.0 SSIMeetup.org
14. General legal considerations
• As a pre-requisite, according to SSI design principles applied in EBSI ESSIF, the person
must have obtained a DID, using a valid method, without any critical dependency of a
third party.
• EBSI ESSIF is limited to natural persons.
• General analysis regarding the legal value of verifiable credentials and their
presentations.
• General legal assessment of DIDs, DID Documents and DID control keys.
CC BY-SA 4.0 SSIMeetup.org
16. Legal scenarios wrt eIDAS alignment
• Very short term scenarios (no changes in Regulation)
1. Use of notified eIDAS eID means and qualified certificates to issue verifiable credentials.
2. eIDAS Bridge: increasing verifiable credentials’ legal value and cross-border recognition.
3. Use current eID nodes to issue SAML assertion based in a VC/VP.
• Short term scenarios (based in interpretation of the Regulation)
4. Use of Verifiable IDs as eIDAS electronic identification means.
5. Issuance of qualified certificates based on a specific DID method and verifiable credential.
• Mid to long term scenarios (major changes in the Regulation)
6. Extend eIDAS Regulation Chapter II to additional VCs for attestations.
7. Regulate the issuance of Verifiable Attestations as a trust service.
8. Regulate the activity of Identity Hubs as a trust service, in support of SSI-based Once Only Principle.
9. Regulate delegated key management as an independent trust service, in support of remote wallets.
10. Regulate a specific type of DLT node as a trust service.
CC BY-SA 4.0 SSIMeetup.org
17. Scenario 1. Use of notified eIDAS eID means and
qualified certificates to issue verifiable credentials
• This use case considers the utilization of an eID for the validation of the identity attributes that
are to be included in any assertion associated to a DID. This would be a scenario in which a
means of identification notified in accordance with the eIDAS Regulation is used to proof the
information that will be included in a Verifiable Credential (eSSIF Verifiable IDs).
• eIDAS Interoperability regulation defines minimum data sets for natural persons and for legal
persons, while Annexes I and III of eIDAS Regulation define the same data set in the case of
qualified certificates.
• The main advantage of using this approach is that the Verifiable Credential inherits the level
of assurance of the eIDAS electronic identification information, allowing a person to get
different Verifiable IDs and leveraging their use in the space of decentralized transactions,
gaining real privacy.
• This is specially true in case the focus on the recognition of specific types of Verifiable ID
Presentations.
CC BY-SA 4.0 SSIMeetup.org
18. Scenario 1. Use of notified eIDAS eID means and
qualified certificates to issue verifiable credentials
CC BY-SA 4.0 SSIMeetup.org
19. Scenario 2. eIDAS Bridge: increasing verifiable
credentials’ legal value and cross-border recognition
• This experience uses qualified certificates to support verifiable credentials and legal evidences
with full legal value.
• Qualified certificates are regulated under articles 28 (natural persons) and 38 (legal persons)
of eIDAS Regulation, and they confirm the identity of the natural person or the legal person.
May also contain other identity data, such as mandates.
• When qualified certificates are operated in the Cloud, they are specially suitable to
authenticate and protect Verifiable Credentials using qualified electronic signatures and
electronic seals, thus providing the maximum legal effect and acceptance to blockchain-based
transactions.
• This technique may generate privacy issues (e.g. allowing re-identification of Verifiable
Credentials issuers that are natural persons).
• Limitation: With qualified certificates we have confirmation of identity but not confirmation of
authority to issue a particular claim.
CC BY-SA 4.0 SSIMeetup.org
20. Scenario 2. eIDAS Bridge: increasing verifiable
credentials’ legal value and cross-border recognition
CC BY-SA 4.0 SSIMeetup.org
21. Scenario 3. Use current eID nodes to issue a SAML
assertion based in verifiable credentials/presentations
• This scenario consider the possibility to incorporate, to a current “regular” eIDAS node,
the capability to accept Verifiable Presentations as a form of user authentication.
• The protocol for the communication in the network of eIDAS identification nodes would
not change, and the assertion issued by the node would be SAML, just as with other
authentication mechanisms.
• The VC/VP should include the minimum data set for the user.
• The DID method should adopt a minimal set of requirements related to the DID control
mechanism, to ensure alignment with the eIDAS Security requirements Regulation.
• Interesting as a “fast-track” procedure for the interoperable adoption of the SSI
technology in relations with public sector bodies.
• But it does not leverage the innovations and privacy enhancements of SSI technologies.
CC BY-SA 4.0 SSIMeetup.org
22. Scenario 3. Use current eID nodes to issue a SAML
assertion based in verifiable credentials/presentations
CC BY-SA 4.0 SSIMeetup.org
23. Scenario 4. Use of Verifiable IDs as eIDAS electronic
identification means
• eIDAS is an appropriate regulatory framework to embody specific SSI systems, such as EBSI
eSSIF Verifiable IDs proposal, aligned with assurance level substantial (or high, depending on
the user device and setup).
• Although electronic identification under eIDAS Regulation is today clearly aligned with
SAML-based infrastructures, nothing in the eIDAS or its implementing acts should prevent the
usage of a SSI system as an electronic identification means.
• Thus, this use case considers a Verifiable Credential as an eIDAS compliant electronic
identification means, enabling –at least– transactions with Public Sector authorities and Public
Administrations and, if so decided by its issuer, also with private sector entities, for AML/CFT
and other uses.
• Again, it would be better to put the focus on a specific type of Verifiable Presentation as an
electronic identification means, including rules on the different Verifiable Credentials
presented.
CC BY-SA 4.0 SSIMeetup.org
24. Scenario 4. Use of Verifiable IDs as eIDAS
electronic identification means
CC BY-SA 4.0 SSIMeetup.org
25. Scenario 5. Issuance of qualified certificates based
on a specific DID method and verifiable credential
• With a technologically neutral, wide, interpretation of the eIDAS Regulation (more specifically,
of the “certificate” definition), it would be possible to consider a specific DID method + a
specific type of Verifiable Credential as a “qualified certificate”, both for natural and for
legal persons.
• As qualified certificates confirm the identity of the subject (signatory or seal creator), this
specific DID method+VC would benefit from the legal effect defined for qualified certificates,
and would also support qualified signatures and qualified electronic seals in blockchain
transactions.
• This type of credential would also qualify as a Verifiable ID, when including the minimum data
set.
• Moreover, this approach allows transitioning from PKI to DPKI & SSI systems, while maintaining
(and even fostering) a valuable market and reusing a convenient and proven supervisory and
liability regime.
CC BY-SA 4.0 SSIMeetup.org
26. Scenario 5. Issuance of qualified certificates based
on a specific DID method and verifiable credential
CC BY-SA 4.0 SSIMeetup.org
27. Scenario 6. Extend the eIDAS notification mechanism to
Verifiable Attestations: enhanced Trusted Issuers management
• eIDAS does not currently offer an appropriate legal framework for other types of
Verifiable Credentials. This is reasonable from the perspective of the legal regime of the
content (e.g. a diploma).
• It would be an opportunity to extend Chapter II of the eIDAS Regulation to schemes for
the self-managed sharing of identity attributes (e.g. eSSIF Verifiable Attestations),
leveraging the legal infrastructure to create a general, abstract, framework for this
process. Sectorial legal norms would define the rules associated to the content (thus
fostering the reusable building block concept).
• It requires the implementation of a Trusted Issuer management scheme, similar to trust
service lists, allowing checks of authoritative sources.
• It would consider issuers both from the public and private sector offering this service, wrt
the data they’re authoritative for, or they can vouch.
CC BY-SA 4.0 SSIMeetup.org
28. Scenario 6. Extend the eIDAS notification mechanism
to Verifiable Attestations: enhanced Trusted Issuers
management
CC BY-SA 4.0 SSIMeetup.org
29. Scenario 6. Extend the eIDAS notification mechanism
to Verifiable Attestations: enhanced Trusted Issuers
management
CC BY-SA 4.0 SSIMeetup.org
30. Scenario 7. Regulate the issuance of Verifiable
Attestations as a trust service
• Following the legal logic of qualified certificates (which could be deployed as DID+VC
under specific rules), it could be possible to define a new trust service, oriented to the
issuance of VCs containing identity attributes (other than foundational identity attributes
contained in VCs issued as qualified certificates).
• Main benefits include benefiting from the all the common rules, supervisory framework
and liability model set up in Chapter III of the eIDAS Regulation (a legal trust anchor).
• It would increase the market for EU qualified trust service providers, helping them
compete in a global scale vs other SSI network’s trust models, requiring issuers to be
“authorized” by the network’s governors (e.g. trust anchors in Sovrin or ARIES).
CC BY-SA 4.0 SSIMeetup.org
31. Scenario 7. Regulate the issuance of Verifiable
Attestations as a trust service
CC BY-SA 4.0 SSIMeetup.org
32. Scenario 8. Regulate the activity of Identity Hubs as a
trust service, in support of SSI-based Once Only Principle
• Identity hubs allow controlling access to personal or corporate information conveyed in
form of VCs.
• They can be seen as repositories of data shared by a subject, directly or when consent
has been explicitly given; in that sense, they support the once only principle (TOOP) in
new scenarios (e.g., when interchanging public sector issued data with private sector
third parties).
• They manage permissions, produce information with legal relevance (e.g., access logs)
and must store data in a trustworthy manner, on behalf of the subject.
• It would be convenient to regulate this activity as a trust service, with the aim to set up a
strict legal framework to protect subjects.
CC BY-SA 4.0 SSIMeetup.org
33. Scenario 8. Regulate the activity of Identity Hubs as a
trust service, in support of SSI-based Once Only Principle
CC BY-SA 4.0 SSIMeetup.org
34. Scenario 8. Regulate the activity of Identity Hubs as a
trust service, in support of SSI-based Once Only Principle
CC BY-SA 4.0 SSIMeetup.org
35. Scenario 9. Regulate delegated key management as an
independent trust service, in support of remote wallets
• DIDs require key management activities. Control is foundational to the SSI concept itself.
• eIDAS advanced electronic signature (for natural persons) require that the signatory has
exclusive control of the signature creation data, a requirement already developed by
CEN & ETSI standards (EN 419 241, parts 1 and 2; TS 119 431-1). When used to
endorse a transaction, the DID key is, actually, signature creation data.
• In many cases wallet providers are already offering server-side wallet services with few
or no guarantees at all, in the best case supported by social recovery mechanisms.
• Although it may reintroduce partial centralization (which may be considered against the
most purist SSI philosophy), it would be convenient to regulate key management as an
independent trust service, to increase server-side wallet providers quality and liability.
CC BY-SA 4.0 SSIMeetup.org
36. Scenario 9. Regulate delegated key management as an
independent trust service, in support of remote wallets
CC BY-SA 4.0 SSIMeetup.org
37. Scenario 10. Regulate a specific type of DLT node as a
trust service
• Finally, we can envision the possibility of extending the eIDAS Regulation to a specific
trust service consisting on the operation of a specific type of node, for a specifically
designed DLT, tailored for the generation of electronic evidences.
• This approach would allow setting up a series of additional requirements aimed to
deploy distributed networks that balance the public/legitimate interest in the legal
certainty of electronic proofs, with the rights and expectations of all parties.
• It could be a baseline service on top of which other services would be reliably deployed
(namely, identity and signature/seal services, timestamping services or electronic
registered delivery services).
• Regulation would cover aspects such as governance and consensus models, time
synchronization, crypto security, software certification… but also legal limits to PII rights,
such as right to modification or right to erasure.
CC BY-SA 4.0 SSIMeetup.org
38. Scenario 10. Regulate a specific type of DLT node as a
trust service
CC BY-SA 4.0 SSIMeetup.org