Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add use case for DIDs+eIDAS #102

Closed
peacekeeper opened this issue Sep 8, 2020 · 24 comments
Closed

Add use case for DIDs+eIDAS #102

peacekeeper opened this issue Sep 8, 2020 · 24 comments
Assignees
@peacekeeper
Labels
PR in review

Comments

@peacekeeper
Copy link
Contributor

peacekeeper commented Sep 8, 2020 •
edited
Loading

Issue w3c/did-core#151 was created a while ago in DID Core to consider mentioning of the E.U.'s eIDAS framework. While in DID Core we probably don't want to go into details about eIDAS specifically, it would be interesting to explain the motivation for this topic in the "Use Cases and Requirements" document.

Possible points to address:

This is one of four inter-related issues: w3c/did-core#390, w3c/did-core#391, #102 (this one), w3c/did-imp-guide#2
This was referenced Sep 8, 2020
Closed
Closed
Open
Closed
@peacekeeper
Copy link
Contributor Author

@ewagner70 would you be interested in adding a section to this "Use Cases and Requirements" document, based on your thoughts about combining DIDs with eIDAS?

@peacekeeper peacekeeper self-assigned this Sep 8, 2020
@ewagner70
Copy link

@ewagner70 would you be interested in adding a section to this "Use Cases and Requirements" document, based on your thoughts about combining DIDs with eIDAS?

@peacekeeper in general yes, but would need support on how to best fit in my contribution and to align the DID combination possibilities from you. When there's a draft of the other chapters, I would propose to have a small meeting, where we align the "technical" details and the storyline and I'll enter my contributions accordingly.

@philarcher
Copy link
Collaborator

@peacekeeper please take a look at the requirements listed at https://w3c.github.io/did-use-cases/#requirements. Would adding a use case specifically about eIDEAS make a material difference to that list? If so, what would be the new requirement(s)? If not, I'm minded to close this issue in 14 days' time without further action. We're trying to finalize this document and so are being a little picky about what to add.

Thanks

@peacekeeper
Copy link
Contributor Author

@philarcher thanks for this explanation.. Myself I don't have the time to write such a use case, but since this topic comes up a lot, I wanted to give others an opportunity to contribute something.

I'm not sure I understand the link between use cases and requirements. Are you saying that you are only interested in new use cases if they have additional requirements that were not covered before by other use cases?

@agropper
Copy link

Regardless of the requirements as they stand, I think this is an essential use-case. In a similar vein, it seems risky for us to gloss over the issues raised by EFF, the Digital Identity Stress Tests (starts at 38:00 in this CCG video) and human-understandable interoperability #101.

@ewagner70
Copy link

yes, this is in my opinion a further use case with importing from and/or referencing to other ID frameworks (such as eIDAS). Depending on the implementation approach (importing or referencing), the specific requirements differ on a technical level.

for a high-level description of the two different approaches see eIDAS-KYC_expert_group_sept_2018_v1.0 (Sovrin eIDAS OpenID).pdf (esp. slide 11)

additional input from my side: Use Case list
eID Use Cases v0.1.pdf
from Financial Services Sector ... this industry is by far the hardest to cover - if an approach can over that, then it can cover almost everything ...

Personal sidenote: I would not underestimate the importance of a cooperation/re-usability of a soon to be enhanced eIDAS as the only eID framework which provides a sound basis (compared to US) and is embedded in a (still) healthy, stable and data protection/privacy oriented political environment (compared to China). Other eID schemes are not advanced enough (Indian, etc.)

by the way, I hope you cover also the authentication setup esp. during enrolment (see guidance papers from BITS and BSI)
BITS.zip
BSI_TR_Assessment of procedures for ID verification_V1.0.4_EN_DRAFT.pdf

@agropper
Copy link

agropper commented Oct 1, 2020 via email

@ewagner70
Copy link

palm biometrics "encrypted" in their "own cloud" ... yes, that's the "spirit" all data protection officers in the world will celebrate ... ;-)

@philarcher
Copy link
Collaborator

@peacekeeper wrote: "I'm not sure I understand the link between use cases and requirements. Are you saying that you are only interested in new use cases if they have additional requirements that were not covered before by other use cases?"

Yes, that's absolutely what I'm saying. We're just dotting the Is and crossing the Ts at this stage, ready to put the doc to bed at TPAC.

If I may paraphrase the comments above: "I don't care about the requirements, I want this use case in there. Here's a load of material you need to go away and read and then distill that down into a use case that may or may not have a material effect on the outcome." If anyone here has time to do all that, be my guest. I'm sure I don't.

If the eIDAS work means that DIDs need to meet a new requirement - one that the DID WG is ready to meet, especially given that we're well past feature freeze - OK, this becomes essential. If, however, the need is to show how DIDs can interoperate with the eIDAS, then I suggest that can be handled readily enough in a blog post or some other publication. It doesn't need to be in the UCR doc that sets out the problem space the WG is working to solve, which in turn breaks the problem down into a set of features that the solution needs to meet.

The rubric document may well be a home for this connection to be made? AIUI, that's about implementation, why DIDs are designed the way they are, how the DID ecosystem fits in with everything else and so on.

@ewagner70
Copy link

@philarcher : thank you for your clarification. as I'm quite new to this exercise and not an indepth SSI experts, I wasn't aware of the respective work so far. @peacekeeper invited me to provide input for the eIDAS use case and (late) contributions was intended that the most important "use case" is the interoperability (or at least import/referencing) can be foreseen or at least referred to. I'm not aware of the "various blog posts or some other publication" and would suggest to at least have a respective reference included in the document, but I take from your words that eIDAS interoperability is not an important topic for the SSI community - which would be a bit disappointing for me.

PS: When you're referring to "Here's a load of material you need to go away and read and then distill that down into a use case that may or may not have a material effect on the outcome." then we share a similar impression - that's the reason for my previous request for support in my contribution. In case you're interested in my inputs, feel free to reach out and let's have a call on that.

@peacekeeper
Copy link
Contributor Author

@philarcher thanks for the clarification, I wasn't aware of this, I thought there was still time to add new use cases even if doesn't change anything about the requirements for DIDs themselves.

If anyone here has time to do all that, be my guest. I'm sure I don't.

Same here, I don't have time to work on this myself, but opened this issue (and three more) to point others to places where they could potentially contribute eIDAS+SSI related content, since this had been requested from various sides.

@philarcher
Copy link
Collaborator

@ewagner70 Please don't take my comment to mean that eIDAS isn't important or that interop with DIDs isn't a desired goal. Of course it's important and interop between systems always makes both of them stronger. I'm not dismissing the use case as such. I am saying that for this document - now close to being completed - I'm reluctant to add new use cases that essentially repeat the need for requirements that have already been identified.

An exploration of eIDAS and DIDs sounds like a very worthwhile task. My only question is whether the DID Use Cases and Requirements document is the right place to record that effort.

@ewagner70
Copy link

@philarcher thank you again for clarification. if eIDAS interop or more generic interoperability with DIDs is not a use case, then in which document/section will this be covered? I'm not sure, but wouldn't that also add some requirements, which are not covered in this document?

@peacekeeper
Copy link
Contributor Author

@philarcher I think the obvious requirement that would be added with this use case is "Legally-enabled identity - These identifiers can be used for legally binding transactions that can be linked to an individual or organization in the real world." (or something like that).

There is some language related to this in https://w3c.github.io/did-core/#binding-of-identity.

In combination with other existing requirements (especially "decentralized" and "privacy preserving") I think this could be really powerful.

Would you be open to accepting a use case that adds this requirement?

@agropper
Copy link

agropper commented Oct 5, 2020 via email

@peacekeeper
Copy link
Contributor Author

@agropper thanks, I like your analogy between flow of identity and flow of currency that can be reversed if a certain threshold is reached. Obviously we have to be very careful with legally enabled identity, that's why in my original message here I included a link to Christopher's webinar on this topic.

@jandrieu
Copy link
Collaborator

jandrieu commented Oct 9, 2020

@peacekeeper We would welcome a PR about Legally Enabled identifiers.

@ewagner70
Copy link

@peacekeeper : as agreed, please create PR based on my inputs I've sent to you ... Thx in advance! KR Eric

@agropper
Copy link

It seems that we could use HD Wallet principles to implement the Zener properties but I'm not sure about the specifics.

Let's assume that a government is able to de-duplicate subjects. (It might use some combination of in-person biometrics, for example, hopefully doing it better than Aadhaar.) The government would operate a public oracle, where any verifier could check whether a public key used to sign a proof was derived from a secret that the government holds for that particular identity. If confirmed, the verifier would know that they could petition the government to disclose the de-duplicated identity. The identifier associated with the subject would be a point of correlation, much like the number on a driver's license today. So a notary would be required as mediator.

A controller would derive a signing key to associate with an otherwise anonymous or same-domain DID. To protect the de-duplicated identifier, a notary would execute the check against the government oracle, countersign the document, and log their notarization activity.

The verifier would then have:

  • an anonymous or same-domain DID for authentication of the subject,
  • a signing key unique to the transaction that is derived by the controller (subject) of the DID
  • a DID for the notary that could itself be checked against the government oracle
  • an opaque tracking number issued by the notary for the transaction
  • the signature of the notary
  • a public log entry made by the notary of the tracking number and an encrypted version of the government ID.

For this to work, the notary's log associating the government identifier with the transaction tracking number would need to be secure. A public log entry might be encrypted with the government's public key. The verifer or anyone else with the tracking number could give the tracking number to the government when seeking to hold the anonymous subject accountable. The government would charge the verifier for the service. The notary might not be involved at that point.

The notary is needed in order to assure the verifier that a de-duplicated identifier was properly encrypted and logged along with the transaction tracking number. The government oracle might do random checks to catch and prosecute rogue notaries.

Some of the discussion around revocation vs. rotation would also be relevant here. The role of notaries as mediators is also discussed in the DIF interoperability workgroup.

@ewagner70
Copy link

@agropper : in general, i agree that deduplication is to be ensured, but I'm really not convinced that the introduction of new actors ("notaries") are the best way to accomplish that. These "notaries" should not be new services from a new kind of actors (such as QTSPs), as this opens up the possibility of misuse/fraud/etc.
We cannot trust/rely on people - therefore, I propose to

  • merge the notary function into the controller function (creating domain/use-case and counter-party-specific DIDs)

  • in a fully automated, decentralized (not all participating nodes have all the information) manner.

  • The technical implementation details are to be aligned with cryptographic and DLT experts ...

... your thought's on that?

@peacekeeper : did you already do the PR?

@agropper
Copy link

@ewagner70 I don't understand how to do what you suggest. Notaries exist because government does not want to deal with individual transactions (a matter of scale) and to protect the privacy of transactions to some extent. If you can find an alternative, then don't use notaries.

@ewagner70
Copy link

@agropper : I didn't say that we don't need the notary function, I merely said we shouldn't introduce new (human based) actors, but include that function via technology alone. As SSI approach is based on numerous (trusted) nodes, the DLT software, running on those nodes, can take over that "notary function" automatically w/o involving government. Furthermore, I merely added the business requirement that the respective notary function results are not stored/propagated to every node in that DLT ecosystem, but only to a subset (max. 30-40%) in order to reduce deduplication possibilites.

@peacekeeper peacekeeper mentioned this issue Oct 12, 2020
Merged
@agropper agropper mentioned this issue Oct 26, 2020
Closed
@agropper agropper mentioned this issue Nov 2, 2020
Merged
@philarcher
Copy link
Collaborator

Thanks everyone - lots of work went into this and I'm pleased to have been able to merge the PR.

@ewagner70
Copy link

Thank you all!

@agropper agropper mentioned this issue Sep 27, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peacekeeper peacekeeper

Labels
PR in review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@agropper @jandrieu @peacekeeper @philarcher @ewagner70