Did-core: Include discussion of eIDAS levels-of-assurance

[Oskar-van-Deventer]

Should we include a discussion of eIDAS levels-of-assurance in did-core and/or did-use-cases?

Europe has standardized three levels-of-assurance for authentication: eIDAS Low, eIDAS Substantial, and eIDAS High, see e.g. https://ec.europa.eu/cefdigital/wiki/download/attachments/40044784/Guidance%20on%20Levels%20of%20Assurance.docx.

I have taken a look at this document. Bare proof-of-possession of a private key ("proof-of-control of a DID") seems to be insufficient to achieve even eIDAS Low, as it is only a single authentication factor and it does not satisfy requirement Low#3: "It is known by an authoritative source that the claimed identity exists and it may be assumed that the person claiming the identity is one and the same". Is this a correct interpretation of the eIDAS Regulation?

All of the eIDAS levels-of-assurance reference "an authorative source". How does that terminology translate to DID and/or verifiable credentials? Is my interpretation correct that even an eIDAS Low authentication requires the exchange of verifiable credentials? What can this "authorative source" be? Apple/Google/Facebook/Samsung? A smartphone? A SIM card? A certified "eIDAS machine"? How would that work in combination with DID and/or verifiable credentials?

Or is this discussion beyond the scope of DID?

Oskar

[nalamillo]

The EBSI eSSIF team is deeply analysing this topic in the context of the eIDAS Bridge capability. Our study includes a legal analysis of the adequacy of current eIDAS Regulation (and implementing acts, including CIR 2015/1502) and change proposals for the future eIDAS v2 (to be considered by the EU Commission, of course).

In few weeks we'll be presenting results publicly, so we could then contribute to this discussion.

[bumblefudge]

I think these are important issues on which to publish clear, actionable guidance, if we want startups with limited legal/compliance departments to be able to participate in the SSI software ecosystem. I am not the right person to speak to whether this kind of guidance/implementation documentation should live in or be linked from this repo, or whether it's enough to publish it elsewhere in RWoT and arvix papers. But I do support publishing it somewhere it will get read by the product designers working on wallets, authentication services, government integrations, etc etc. I still haven't pulled the trigger on Buenos Aires yet, but if I go, I hope to be useful to this particular conversation, whatever form it takes!

[Oskar-van-Deventer]

@nalamillo , @bumblefudge , thanks for these insights.

My worry is that all the advanced DID stuff that we are doing is unsuited to achieve even the lowest eIDAS level of assurance, and that hence DID is now unsuited for business/government application. I wish to find out whether other share my worry, and if so, how we could address this issue.

[nalamillo]

We fully share this concern. The aim of the eIDAS Bridge is precisely to get, at least, eIDAS LoA Substantial. That means working in the DID control keys, possible aligned with the eIDA eSign/eSeal regulation.

Any input is welcome. Once we publish specs (after authorisation from the project management), we'll have a really interesting debate, I'm sure.

[awoie]

In this regards, we should also think about the different LoA components, e.g., provisioning / issuance, identity verification, security of keys and authentication etc. There are different assurance level frameworks such as eIDAS, NIST 800-63B, ISO/IEC 29115 etc. that have that distinction.

My approach would be (oversimplified):

• provisioning / issuance / identity verification --> W3C VC related (trust certain issuer DIDs)
• security of keys (TEE vs SE vs software etc.) and authentication (MFA vs single factor) --> combination of both W3C VC/VP and DID. This is an area of not-well-explored territory. There might be some DID methods that can only be created by highly trusted entities (e.g., trusted ecosystem, gov etc.) and guarantee a certain assurance level, so one could derive the LoA from the the DID method itself but that is not what most people in the community want. Another approach is to leverage externally verifiable certifications of the underlying authenticator, e.g., FIDO attestations. The issue in general is that in a completely open system where everyone could be an identity wallet provider, it is quite hard to verify that an identity wallet achieves a certain LoA.

Especially for authentication, I haven't seen more concrete work on MFA. Note, to achieve MFA, the authenticator needs to perform authentication in a way that allows a verifier to check that two factors were used. This means it is not sufficient to have your mobile device (possession of a DID) and unlock your mobile device (biometrics) to authenticate a transaction because that happens only locally on the device itself. This is one of the work items that the Auth WG in DIF wants to explore.

Updated:
I would love to have a discussion and see what people have used in this community.

Updated:
I guess, one could certainly use WebAuthn/FIDO additionally after signup. My question is, is there a need to use WebAuthn/FIDO to sign a DID Auth challenge or W3C VP, or do people believe that there is no need to combine these concepts? Because the W3C VPs need be trusted and there is no information how the user was authenticated to generate the VP on the device, I do see some need there.

[awoie]

I guess we could delegate that issue to the credentials exchange protocol, or we include that information in the W3C VP but then we have to agree on some proof format for that. Many options but to achieve interop, we should probably sit together :)

[Oskar-van-Deventer]

We fully share this concern. The aim of the eIDAS Bridge is precisely to get, at least, eIDAS LoA Substantial. That means working in the DID control keys, possible aligned with the eIDA eSign/eSeal regulation.
Any input is welcome. Once we publish specs (after authorisation from the project management), we'll have a really interesting debate, I'm sure.

@nalamillo I sent you a private email about this at n**@astrea.cat. Is that the correct email address?

[talltree]

@Oskar-van-Deventer I was at Identity North in Vancouver this past week and the question also came up there. I'm hoping we get to talk about this at the W3C DID Working Group F2F meeting this coming week as I believe that the right combination of VC proofs under the right DID method can meet almost any level of assurance. Thus we must discuss those conditions. Looking forward to that this week.

[awoie]

@Oskar-van-Deventer @talltree I would be interested in this discussion as well.

[Oskar-van-Deventer]

We may also want to consider liaising with the Fido Alliance: https://fidoalliance.org/. Fido enables local biometric authentication, PIN and the like. So Fido seems compatible with a decentralized approach, while delivering a higher level-of-assurance than bare DID. Could there exist a "DID-Fido bridge" that enhances DID with Fido-based authentication? E.g. with Fido verofiable-credentials getting associated to a DID, or so?

[ewagner70]

Gentlemen, the eIDAS Integration/Bridging is inevitable for the future success. In order to get an overview about the necessary components, I would like to draw your attention to the recently endorsed European Commission Expert Group paper on eIDAS/remoteKYC for Financial Services (which I'm happy to share with you). The necessary components are outlined in the following overview:

the referenced paper can serve as "business requirement" paper on how to enhance eIDAS (ideally based on SSI components to circumvent intermediaries) - along with the respective authentication guidance papers from BITS/Norway and BIS/Germany.

In case you're interested, please contact me directly.

[kimdhamilton]

@ewagner70 I'm very interested but don't know how to reach you. My email is in my github profile.

In general DCC will be extremely interested in this topic

[nalamillo]

@kimdhamilton by end February I think the eIDAS Bridge report will be available, dealing precisely with this topic, in the EBSI eSSIF project led by EBP and EU Commission

[bumblefudge]

Maybe as banks start implementing PSD2 it will bring new urgency to the conversation around finetuning or re-interpreting eIDAS? Perhaps I/we should be reaching out to this guy, he might have some useful inside intell, from the PSD2 side of things:
https://twitter.com/Michal_Tabor/status/918170305729835008

I too would love to be in the loop, and my email is also linked from my profile, please CC me if anything like a group email conversation or a working group arises from this issue!

[ewagner70]

@bumblefudge : would love to second that, but QWACs/QSEALs are only one trusted service that could rely on eIDAS. apart from PSD2 being a very limited success (to avoid the term "failure"), we're talking about a more fundamental approach, the (remote)eKYC approach, which is much more sophisticated and comprehensive ...

[bumblefudge]

Sure, my point was that the people involved directly in that limited success might be useful to talk to, but maybe the EC paper you mentioned explains why you disagree? In any case, I would love to see that EC paper and the Norwegian guidance (I've already got the German one), how can I contact you?

[awoie]

Gentlemen, the eIDAS Integration/Bridging is inevitable for the future success. In order to get an overview about the necessary components, I would like to draw your attention to the recently endorsed European Commission Expert Group paper on eIDAS/remoteKYC for Financial Services (which I'm happy to share with you). The necessary components are outlined in the following overview:

the referenced paper can serve as "business requirement" paper on how to enhance eIDAS (ideally based on SSI components to circumvent intermediaries) - along with the respective authentication guidance papers from BITS/Norway and BIS/Germany.

In case you're interested, please contact me directly.

@ewagner70 Two years ago I also worked on a paper how to combine eIDAS + SSI, so I'm highly interested in this work. Would love if you could share more. My email address is in my profile.

[msporny]

We need someone in the WG to take this issue. Someone please volunteer to process it.

[peacekeeper]

@msporny I'm partially familiar with this, assigning it to me

[nalamillo]

I'd like also to contribute, if possible.

[peacekeeper]

@nalamillo in general, anyone can contribute, not just the assigned person. Also feel free to assign it to yourself if you want to drive this issue forward!

[nalamillo]

By now, I'll just try to contribute. Still working in the EBSI ESSIF report... ending it. Once finished, I'll have time for this interesting initiative.

[Oskar-van-Deventer]

@msporny Please clarify "contribute". Do you mean "shoot in a PR"? Or something else?

[dlongley]

@Oskar-van-Deventer,

PRs and reviewing PRs are the best way to contribute. You can also contribute by making proposals and discussing concrete ways to move forward in the issue -- but then those need to be turned into PRs.

[Oskar-van-Deventer]

@peacekeeper , @nalamillo , all,
I propose that we document information on eIDAS levels-of-assurance in a new informational annex.

1. The annex would be titled "§X eIDAS levels of assurance (Informational)"
2. The annex would provide information and references about eIDAS, its levels of assurance and its attributes
3. The annex would provide the insight that bare self-attested DIDs + DID documents would achieve only the lowest level of assurance
4. The annex would explain how higher levels of assurance may be achieve with verifiable credentials of the type that CEF EBSI ESSIF calls "verifiable identity"
5. The annex would sketch the DID-eIDAS-bridge solution proposed by CEF EBSI ESSIF, making clear that this is just one of the possible approaches to achieve strong authentication
6. The annex might also include discussion about the eIDAS-bridge approach, e.g. the federated-identity nature of eIDAS with its associated privacy issues, and possible work-arounds

What do you think?

Oskar

[ChristopherA]

Oskar,

Could this annex suggest that no higher level of eiDAS assurance level should be requested than what is needed to manage the risks or business purpose?

I worry that we’ll move to a world where only the highest levels of assurance are allowed, without regard to that the higher the level of assurance is, the higher risk of correlation and possible privacy abuse.

— Christopher Allen

[ewagner70]

Oskar,

Could this annex suggest that no higher level of eiDAS assurance level should be requested than what is needed to manage the risks or business purpose?

I worry that we’ll move to a world where only the highest levels of assurance are allowed, without regard to that the higher the level of assurance is, the higher risk of correlation and possible privacy abuse.

— Christopher Allen

in general fine, but to be honest - the use cases where low/substantial LoA (according to eIDAS) will be sufficient are becoming fewer and fewer ...

[ewagner70]

@peacekeeper , @nalamillo , all,
I propose that we document information on eIDAS levels-of-assurance in a new informational annex.

1. The annex would be titled "§X eIDAS levels of assurance (Informational)"
2. The annex would provide information and references about eIDAS, its levels of assurance and its attributes
3. The annex would provide the insight that bare self-attested DIDs + DID documents would achieve only the lowest level of assurance
4. The annex would explain how higher levels of assurance may be achieve with verifiable credentials of the type that CEF EBSI ESSIF calls "verifiable identity"
5. The annex would sketch the DID-eIDAS-bridge solution proposed by CEF EBSI ESSIF, making clear that this is just one of the possible approaches to achieve strong authentication
6. The annex might also include discussion about the eIDAS-bridge approach, e.g. the federated-identity nature of eIDAS with its associated privacy issues, and possible work-arounds

What do you think?

Oskar

as proposed in our paper, why not referring to:

• Low LoA: self-declared
• Substantial LoA: via RITPs (reliable independant third parties)
• High LoA: via direct access to Trusted Sources, i.e. the original issuer of the respective identity attribute(s) with EBSI/eSSIF as facilitator to avoid RITPs and gain direct access to these Trusted Sources

[nalamillo]

@ChristopherA, under GDPR it would be illegal to require a level of assurance that is not required for that particular purpose. In any case, as eIDAS is mainly regulating an identity federation for public procedures between citizens and public sector bodies, there is a Minimum (identity) Data Set that MUST be part of a Verifiable Credential or, at least, a set of Verifiable Credentials in a Verifiable Presentation.

[ChristopherA]

RITP? What is this an acronym for?

— Christopher Allen

[nalamillo]

as proposed in our paper, why not referring to:

• Low LoA: self-declared
• Substantial LoA: via RITPs (reliable independant third parties)
• High LoA: via direct access to Trusted Sources, i.e. the original issuer of the respective identity attribute(s) with EBSI/eSSIF as facilitator to avoid RITPs and gain direct access to these Trusted Sources

@ewagner70, while I like the approach, eIDAS LoA don't really work this way, at least right now. I think we should align with the current legislation.

[ewagner70]

@nalamillo : correct, that's why we propose to enhance eIDAS (which is currently focused on governmental services only) to make it usable for private sector (f.ex. Financial Services, etc.)
@ChristopherA : RITP = Reliable Independent Third Party

[ChristopherA]

Personally and professionally I think it is time we should start pushing back some on government regulations and requests for higher LOA. We need regulations for identification minimization as much as we do personal data minimization in GDPR.

This is exactly the slippery slope I worry about that I discuss in my talk about misuse of identity information collected for good purposes that used for evil in WWII: https://docs.google.com/presentation/d/1Rtx30fB-U8MStlMrDIc-FneCrr8mel421YNbAdofDwM

— Christopher Allen

[nalamillo]

@ewagner70 @Oskar-van-Deventer One of the issues with current eIDAS is the notion that a electronic identification means is issued by an issuer with a specific liability model, under the last authority of the notifying Member State. Thus, is quite far from the philosophical foundations of SSI. In my view, it is quite easy to model verifiable credentials aligned with eIDAS Regulation, leveraging a pre-existing DID. In any case, in eIDAS there's nothing such as self-asserted claims, so in this sense, it can be an enhancement compared to the current FIM approach.
Just for clarification, I see quite difficult, of course, to include any personal identity attribute in the DID Document itself. Thus, a solution will need to combine a specific DID method with a specially crafted VC.

[Oskar-van-Deventer]

@ChristopherA , @ewagner70 , @nalamillo please suggest concrete texts that we could put into the informative annex. E.g. the suggested combination of "a specific DID method with a specially crafted VC", or technical directions that help push back some on government regulations and requests for higher LOA.

Also, we could add yet another informative annex about integration/bridging of DIDs with FIDO credentials. FIDO credentials are much more in line with federated identities like eIDAS, whereas FIDO credentials could likely meet some of the LoA requirements of eIDAS.

[ewagner70]

@Oskar-van-Deventer @ChristopherA @nalamillo : I would suggest to involve also Markus Sabadello (@peacekeeper ) to provide respective wording as he was already heavily involved in a respective technical PoC in Austria.

[bumblefudge]

For the record, I'm still happy to help synthesize and wordsmith an appendix document for review by WG members. I'm just waiting on Nacho's report and a few other input documents, thanks to everyone on the thread that has been sharing bibliography with me.

[kdenhartog]

We found that when working on trust frameworks in NZ we encountered very similar thinking that much of the SSI tech is being leveraged to provide better guarantees, while putting little thinking of how other systems would integrate and work alongside with high trust identity systems.

I found that referencing the Five Mental Models of Identity paper from RWoT was useful in helping to reframe and explain how other identity systems can be thought about and how we should trying to integrate different mental models.

[peacekeeper]

I think @Oskar-van-Deventer 's list of topics makes a lot of sense.

I just wonder how much of this actually belongs into the DID Core specification. For example, see the following language in section 11.2.3 "Authentication and Verifiable Claims":

_"A DID and DID document do not inherently carry any PII (personally-identifiable information). The process of binding a DID to something in the real world, such as a person or a company, for example with credentials with the same subject as that DID, is out of scope for this specification."_

---

If there are missing technical features or considerations that are directly related to DIDs, then we can add that to the DID Core spec, for example:

• We could write something about the security of keys, and about FIDO attestations.
• We could also add generic considerations about LoAs as well as approaches of binding DIDs to a legal identity.

But I think the specific topic and details of eIDAS integration/bridging is an application of DIDs+VCs, rather than an inherent built-in feature of those technologies. Therefore I think it would be valuable to contribute eIDAS-related content to the following documents rather than (an annex of) the DID Core spec:

• DID Use Cases and Requirements - https://github.com/w3c/did-use-cases/
• DID Implementation Guide - https://github.com/w3c/did-imp-guide

[Oskar-van-Deventer]

@peacekeeper Markus, excellent point. It feels to me that the DID Implementation Guide may be the best place for this. I notice that that document is essentially empty. Are people working on it?

Anyway, the section titles could be

1. Strong authentication
   5.1 General
   (Introducing the authentication limitations of self/anyone-issued DIDs and DID-documents)
   (Also adding Christopher Allen's above warnings)
   5.2 DID and eIDAS
   (Possible architecture of DID-eIDAS bridge and other results from EBSI-ESSIF)
   (Discussion of combining DID with Verifiable Identity VCs)
   5.3 DID and FIDO
   (Possible architecture of DID-FIDO bridge)
   ...

Procedural question: did-imp-guide is a different repository. So should we then move the issue and PR there?

[peacekeeper]

@Oskar-van-Deventer the DID Implementation Guide was created after discussions at the Amsterdam F2F meeting, see here for the proposal: https://lists.w3.org/Archives/Public/public-did-wg/2020Feb/0011.html

The fact that it's empty right now should not intimidate anyone, someone has to be the first to add content :)

I think ideally we would split this up and do something like the following:

• [x] [DID Core Spec Section 11.2.3 Authentication and Verifiable Claims](https://w3c.github.io/did-core/#authentication-and-verifiable-claims): Maybe rename this to "Real-World Identity", or alternatively create a new subsection. Add a short note that it's possible to establish a binding between DIDs and a legal identity, but don't go into details too much.
• [x] [DID Core Spec Section 11. Security Considerations](https://w3c.github.io/did-core/#security-considerations): Add a subsection with technical considerations about the security of keys, maybe with a reference to FIDO.
• [x] [Use Cases and Requirements](https://github.com/w3c/did-use-cases/): Add a use case. (Why is this important? What can you do once you support the use of DIDs with legally enabled identity systems such as eIDAS? Mention LoAs. What are the risks? -> Christopher's warnings)
• [x] [DID Implementation Guide](https://github.com/w3c/did-imp-guide): Add one or more sections. (How is the DID-eIDAS bridge implemented, how are DIDs and VCs used to achieve different LoAs? How would a DID-FIDO bridge work?)

Thoughts? Volunteers? :)

[veikkoeeva]

@nalamillo Are the EBSI eSSIF bridge document(s) you refefer to at https://joinup.ec.europa.eu/collection/ssi-eidas-bridge?

[nalamillo]

Yes, that's the repository where the project documentation has been published. It is quite dependent on the EBSI ESSIF specs, but the concept could be easily adapted to other approaches, such as Hyperledger anoncreds. The legal report analyses also other challenges regarding SSI vs eIDAS.

[peacekeeper]

Thanks for the update, looks like a lot of new interesting material on the topic! Still the question remains, who would like to contribute content to the DID Spec and related documents?

[nalamillo]

I can volunteer. One of the topics we've been looking at in the eIDAS Bridge is the need to include information (in the DID document) about the "security level" of a DID-controlling key, both for authentication and for VC signature purposes.

[ewagner70]

Thanks for the update, looks like a lot of new interesting material on the topic! Still the question remains, who would like to contribute content to the DID Spec and related documents?

What about you, Marcus ... I can think of only few worthy/capable ;-)

[peacekeeper]

Looks like @nalamillo is having an interesting webinar about SSI and eIDAS this week: https://ssimeetup.org/introducing-ssi-eidas-legal-report-ignacio-alamillo-webinar-55/

BTW while this issue here is assigned to me, this doesn't mean that I will be the one doing the work of writing concrete text. I made some suggestions above on what eIDAS-related content could be added to what documents, and I am hoping for contributions by those who care the most about this topic!

[OR13]

We should split this issue up based on https://github.com/w3c/did-core/issues/151#issuecomment-603932879 and close this issue after cross linking.

[peacekeeper]

@Oskar-van-Deventer @ewagner70 @nalamillo @awoie please let us know if you have thoughts on splitting up this issue as suggested above, and perhaps indicate your interest/availability to contribute actual content.

[awoie]

To me, the proposal makes sense. It is valuable to add these sections in separate documents.

[nalamillo]

I also agree with the proposal. Can volunteer to the Use case part (which at the end of the day explains the importance of having something such as a Level of Key Assurance), but I'm not familiar with the procedure to contribute, sorry.

[burnburn]

@peacekeeper can you follow up here on next steps?

[peacekeeper]

Based on the proposal https://github.com/w3c/did-core/issues/151#issuecomment-603932879 earlier in this thread, I created four issues to split up the topic, and I will ping people in those respective issues who I think may be interested in addressing them. Of course anyone feel free to work on any of them:

• https://github.com/w3c/did-core/issues/390
• https://github.com/w3c/did-core/issues/391
• https://github.com/w3c/did-use-cases/issues/102
• https://github.com/w3c/did-imp-guide/issues/2

[msporny]

We should split this issue up based on #151 (comment) and close this issue after cross linking.

The issue has been split and is being tracked elsewhere, marking this as pending close. This issue will be closed in 7 days unless there are objections.

[peacekeeper]

+1 to closing, since the issue has been split up into smaller ones.

[kdenhartog]

I've not seen any objections recorded and 7 days have now passed. Closing this.