search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
42 stars 6 forks source link

[PROPOSED WORK ITEM] did.actor test infrastructure for did:web #163

Closed OR13 closed 3 years ago

OR13 commented 3 years ago

New Work Item Proposal

Include Link to Abstract or Draft

https://did.actor/ https://github.com/transmute-industries/did.actor

This is a GitHub Pages repo which hosts multiple did:web identifiers for the purpose of testing and development. It includes examples of using did:web with verifiable credentials and revocation lists.

We're proposing this as a work item due to the recent interest in did:web, and the need to collaborate on best practices for integrating did:web into other ccg work items, such as:

We're tracking the emerging privacy related issues regarding did:web, and we want to provide some example of "good" and "bad" use of did:web, in a way that is clear for developers, and that can support the did:web spec as well as the related specs mentioned above.

List Owners

@OR13 @mprorock

mprorock commented 3 years ago

big fan of this as it will help consolidate testing and provide a standard model for us to work with did:web in a clean way in other ccg efforts (such as on the universal-wallet) while ensuring privacy and security best practices are followed in reference implementations

longpd commented 3 years ago

This is a useful approach to identify how to use did:web safely, but also to push thinking to uncover and highlight limitations it may not be able to overcome easily.

agropper commented 3 years ago

I agree. Let me propose a use-case based on the HIE of One Trustee implementation. In the first generation Trustee, before DID and VC standards, we built the patient's Trustee authorization agent on the assumption that requesting parties (a doctor) would approach the agent with either a uPort wallet or a federated OpenID Connect IDP.

As we move to Trustee 2.0, the doctor's wallet becomes DID-standard and credentials may be VCs. If we want to harmonize with the OIDC functionality, we might allow the doctor to have a did:web resolved to a well-known location in the hospital domain. The doctor, however, should still keep control of their private credentials for obvious accountability reasons.

In other words, when the patient's Trustee decides to authorize a doctor using a did:web because they trust the hospital to keep the doctor accountable, the doctor must control the signing keys of the DID Document, not the hospital.

OR13 commented 3 years ago

@agropper The real problem with did:web is that whoever controls the domain associated with the DID sees, all the resolution requests for the DID.... So if I am a hospital and I make DIDs for all my patients, I can see every time anyone resolved a patient DID.... (did:web is not good for identifying subjects that require privacy)

did:web might be appropriate for doctors who work at hospitals, but its probably not a good solution for patients.

It's completely possible for the hospital to provide for the doctor's did, but not control the doctors keys.

agropper commented 3 years ago

Exactly. Why can't we just say exactly that?

I listened to the did:web session at IIW. We all understand how SSI solves federation problems. did:web and oracles (entities that send credentials directly to the verifier without a relay through some holding storage) are going to play a major role in the adoption of SSI. An oracle could have a did:web even if the subject of the credential doesn't use did:web for themselves. This relates to our conversation around Confidential Storage https://github.com/decentralized-identity/secure-data-store/issues/114#issuecomment-725702014 where I maintain that authorization for access to an oracle might be the same protocol that controls access to an EDV.

On Wed, Nov 11, 2020 at 4:19 PM Orie Steele notifications@github.com wrote:

@agropper https://github.com/agropper The real problem with did:web is that whoever controls the domain associated with the DID sees, all the resolution requests for the DID.... So if I am a hospital and I make DIDs for all my patients, I can see every time anyone resolved a patient DID....

did:web might be appropriate for doctors who work at hospitals, but its probably not a good solution for patients.

It's completely possible for the hospital to provide for the doctor's did, but not control the doctors keys.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/163#issuecomment-725692836, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMNZFGKP2HAJVQCSRLSPMEWXANCNFSM4TSG337A .

peacekeeper commented 3 years ago

I have been historically critical of did:web, since out of the four essential characteristics of DIDs (decentralized, persistent, cryptographically verifiable, and resolvable), did:web only supports the last. This method is not suitable for building Self-Sovereign Identity infrastructure.

However, given the commercial interest in this method, it seems unavoidable, and doing more work on examples is logical.

mprorock commented 3 years ago

Good call out. This is primarily commercial driving this need, though there are surely better options available in an ideal world, especially from a self sovreign standpoint. Did:web however definitely serves a real purpose for integration with key customers for us though.

Michael Prorock CTO, Founder mesur.io

On Wed, Nov 11, 2020, 18:05 Markus Sabadello notifications@github.com wrote:

I have been historically critical of did:web, since out of the four essential characteristics of DIDs (decentralized, persistent, cryptographically verifiable, and resolvable), did:web only supports the last. This method is not suitable for building Self-Sovereign Identity infrastructure.

However, given the commercial interest in this method, it seems unavoidable, and doing more work on examples is logical.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/163#issuecomment-725710610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2VJZF26F3XPSDAKIXEGZLSPMKFHANCNFSM4TSG337A .

aniltj commented 3 years ago

The real problem with did:web is that whoever controls the domain associated with the DID sees, all the resolution requests for the DID

Could you contrast this with an organization deploying a DID Resolver, and having the same visibility into the DID resolution requests?

OR13 commented 3 years ago

@aniltj sure, consider the following:

Organization A, Organization B, Organization C have a pilot together.

Organization A runs a resolver for the pilot that everyone uses.

Organization A now knows when all DIDs in the pilot are resolved (assuming no caching).

Some of what Organization A knows might be related to interactions between B and C, which there is no reason for Organization A to know.

Now consider all organizations use did:web, and run their own resolvers for their organization.

Each organization only sees when its DIDs are resolved (regardless of who is resolving them).

In short, an http resolver sees all resolution requests, a did:web host sees only resolution requests for its origin.

From a privacy perspective, multiple did:webs and no centralized resolver is better than a central resolver and no did:webs....

Here is how information is revealed with and without did:web.

Case 1

  1. verifier receives credential issued by did:elem
  2. verifier resolves did:elem from an http resolver
  3. the resolver knows the did is being accessed, the issuer does not.

Case 2

  1. verifier receives credential issued by did:web
  2. verifier resolves did:web from an http resolver
  3. the resolver knows the did is being accessed, AND the issuer knows the did is being accessed.

We consider Case 2 to be bad, because the issuer does not need to know when credentials it has issued are being used.

In the case that the http resolver relies on a "full node" for the issuer did method, the resolver is the only entity that knows the did being used, because 100% of the resolution process happens at the resolver / full node.

This is the case for running a full node of did:elem / did:trustbloc / did:v1 / did:photon.... this is not the case for did:web, since did web's resolution process relies on notifying the issuer that it's did is being requested.

verifier -> http resolver -> did:web, issuer web server

vs

verifier -> http resolver -> did method node, blockchain / storage

If the blockchain is public / permissionless anyone can "run a node / http resolver"

If the blockchain is permissioned everyone must trust the node operators, and since they are finite / known, an attacker might observe all of them and recover the information regarding which DIDs are being accessed when (but the issuer would still not know this information).

A notable difference between did:web and permissioned ledgers is that usually identifiers in a permissioned ledger can be resolved from any node in the ledger network, vs did:web which always relies on notifying the issuer web server.

aniltj commented 3 years ago

We consider Case 2 to be bad, because the issuer does not need to know when credentials it has issued are being used.

Agreed. This is very much the classic 'Phone Home' problem we are seeking to mitigate with the verifiable credential model that breaks the direct dependency between a Verifier (Relying Party) and the Issuer (Identity Provider).

My position on this continues to be that did:web makes sense for NPE (non-Person entities), particularly organizations, who need to identify themselves as Issuers and NOT for use as identifiers assigned to people/person in a VC.

agropper commented 3 years ago

My position on this continues to be that did:web makes sense for NPE (non-Person entities), particularly organizations, who need to identify themselves as Issuers and NOT for use for for persons / subjects in a VC.

Would we then agree that NPE Issuers as a root of trust (oracle) should still support individual staff members as the notary signing with separate DIDs? This seems important as we move toward auditability in zero-trust-architecture designs.

aniltj commented 3 years ago

Would we then agree that NPE Issuers as a root of trust (oracle) should still support individual staff members as the notary signing with separate DIDs?

I have not thought about the notary use case deeply enough to answer this question.

My current work is focused directly on two areas (1) As the sole/direct/authoritative issuer of credentials and (2) as the Verifier of credential(s) issued outside our administrative boundary .. neither function to be envisioned to be delegated to another entity.

OR13 commented 3 years ago

@agropper there are cases where you don't actually want the individuals signing on behalf of the organization to be identified, because it can raise questions regarding liability.... from a technical perspective there is nothing prevent "organization" vs "chief risk officer" signatures... they function exactly the same... just one of them lets you through the CRO under the bus easier.

This is more of a question regarding should the DID Subject of a Credential be restricted to "People"... I think the answer to that will be a resounding no, given the great type debate we just had in the DID WG... the issuer DID domain MUST NOT be restricted in ways that could lead to identifying / harm to individuals.

agropper commented 3 years ago

@OR13, you're not wrong but I'm not as sanguine as you about the breakdown in adoption patterns for SSI. The current IAM model is dominated by federation and identifies individuals under the authority of the federation. If I invite your email address to my Google doc I'm trusting Google to restrict access to you and route any related message accordingly.

I don't see this as having to do with the "People" issue. The IDP could be vouching for anything.

Regardless of what fraction of SSI uses will be 'truly' self-sovereign, It seems to me that there's no purpose served in treating the legacy federations as out of scope.

peacekeeper commented 3 years ago

I agree with @OR13 's analysis above. Since domain names are not "decentralized identifiers", there are always central authorities (the webserver, DNS operators, etc.) that can observe (and manipulate) the resolution requests.

From a privacy perspective, multiple did:webs and no centralized resolver is better than a central resolver and no did:webs....

Even better from a privacy perspective would of course be no did:webs and no central resolver (i.e. each verifier running its own instance of a resolver).

David-Chadwick commented 3 years ago

This is very much the classic 'Phone Home' problem we are seeking to mitigate with the verifiable credential model that breaks the direct dependency between a Verifier (Relying Party) and the Issuer (Identity Provider).

There is a difference between the holder phoning home to its own issuer, and the verifier phoning "home" to the holder's issuer. You should differentiate between the two. The VC model has always said it wants to stop the latter, but has never said that it wants to stop the former as far as I know. In particular, stopping the verifier phoning "home" must also be prevented via the revocation mechanism used by the Issuer.

OR13 commented 3 years ago

@David-Chadwick thats correct, and in fact, there is a criticism of https://github.com/w3c-ccg/vc-status-rl-2020 specifically for the "verifier phoning the issuer to check for revocation status"... its why the spec introduced such a large revocation space, attempting to provide heard immunity....

The issuer can't tell which of the 10,000 VCs the verifier is looking at.

The difference with did:web is that potentially every presentation regardless of the credentials is observable to the "holder's web server"... which is a problem is they don't own it.

Consider this revocation list that alice maintains: https://did.actor/alice/credentials/status/3.json

Alice uses did:web and http revocation list, but github / microsoft sees 100% of the resolutions related to both the did and the credentials related to it.

TallTed commented 3 years ago

@David-Chadwick --

There is a difference between the holder phoning home to its own issuer, and the verifier phoning "home" to the holder's issuer.

That line makes no sense, and it makes me struggle to understand what follows. A holder doesn't have an issuer. A holder holds something (e.g., a VC); the holder is not itself the thing it holds, and thus a holder has no issuer! If we cannot maintain use of correct labels for each entity when discussing a VC/DID process flow, how can we expect folks who have not been participating in these discussions to keep them straight?

David-Chadwick commented 3 years ago

A holder doesn't have an issuer.

The way I see the VC data model from figure 1 of the W3C recommendation is that the holder has relationships with very many issuers, in which each issuer issues one or more VCs to the holder. So the holder does indeed have many issuers, each of which issue it with one or more VCs. I hope that clarifies your understanding.

BTW, there is no DID process flow in the W3C Recommendation as far as I can tell. There is a VC process flow, but VCs have URIs, which are not necessarily DIDs :-)

TallTed commented 3 years ago

@David-Chadwick --

A VC has an issuer. A holder does not have an issuer. (You might make a case that the human parents of a human holder are issuers of that holder, but I think that relationship is not part of the current discussion.)

A holder holds one or more VCs, each of which has an issuer, who may have issued those VCs directly to the current holder, or the current holder may have received the VCs through a chain of any number of previous holders stretching back to the issuer.

A holder may have relationships with the issuer of a VC it holds, but the receiver of a VC (via a VP), who then becomes a verifier, cannot presume that the VC went directly from its issuer to the current holder to the current verifier.

A verifier does not generally verify the holder, nor the presenter, nor the issuer, per se. A verifier typically verifies a VC, which may include verification that it was issued by the issuer it claims.

Blurring the lines between these entities/roles, even among folks who know the discussion space well and can (usually, hopefully) mentally substitute the correct terms when considering what you've said, is not good practice, and will in time, if not immediately, lead to someone substituting the term for an entity you did not intend, and so to your message being misunderstood, and thereby reaching conclusions you did not intend -- which may be to your benefit or detriment; this is impossible to predict. Worse, getting into the habit of such blurring among such knowledgeable crowds may lead to continuing that blurred pattern among groups of people who are less knowledgeable about the discussion space -- who will surely repeat what they've heard from the knowledgeable speaker -- thereby making it harder to keep this already complex subject understood by the general public.

(This CCG issue is discussing did.actor and did:web, so referring back to the DID process flow [a/k/a lifespan] seemed appropriate. Anywhere from all to none of the URIs involved in a VC process flow might be DIDs; presumably at least one URI in the current discussion is a DID, because why else would this discussion be taking place here?)

agropper commented 3 years ago

This seems relevant to our 'phone home' discussions: https://scotthelme.co.uk/deja-vu-macos-hits-ocsp-hurdles/#update

David-Chadwick commented 3 years ago

This seems relevant to our 'phone home' discussions: https://scotthelme.co.uk/deja-vu-macos-hits-ocsp-hurdles/#update

Thanks @agropper for pointing us to this article.

kimdhamilton commented 3 years ago

@OR13 wlll move

vsnt commented 3 years ago

@OR13 here are the additional proposed work item questions.

  1. What are you trying to do? Articulate your objectives using absolutely no jargon.
  2. How is it done today, and what are the limits of current practice?
  3. What is new in your approach and why do you think it will be successful?
  4. Who cares? If you are successful, what difference will it make?
  5. What are the risks?
  6. How much will it cost?
  7. How long will it take?
  8. What are the mid-term and final “exams” to check for success?
  9. How are you involving participants from multiple skill sets in this work item? (technical, design, product, marketing, anthropological, UX)
  10. How are you involving participants from various global locations in this work item? (Americas, Euro, Asia-Pacific, South America)
  11. How do you plan to involve non-technical subject matter experts & end users of your work item? How will you work item improve their lives?
  12. What actions are you taking to make this work item accessible to a non-technical audience?
OR13 commented 3 years ago
  1. What are you trying to do? Articulate your objectives using absolutely no jargon.

Develop a set of shared test accounts and user personas for working with emerging digital identity and credentialing standards.

  1. How is it done today, and what are the limits of current practice?

Private keys and identifiers are shared ad hoc, no background of context for personas is provided, identifiers for accounts are not human readable, leading to confusion and human error.

  1. What is new in your approach and why do you think it will be successful?

Single github repo can manage many test accounts, with control authority keys co-located with background / persona text about the accounts. Much easier to use than anything else in the space.

  1. Who cares? If you are successful, what difference will it make?

Developers / Designers will spend less time tracking down bugs, or setting up demos. Less likely to accidentally use private keys that are not meant to be used for testing.

  1. What are the risks?

People may accidentally commit private keys that are used elsewhere.

  1. How much will it cost?

$0

  1. How long will it take?

It's done, but work items go on as long as folks have improvements to make.

  1. What are the mid-term and final “exams” to check for success?

Seeing the test identifiers being used in other specs / demos would indicate success.

  1. How are you involving participants from multiple skill sets in this work item? (technical, design, product, marketing, anthropological, UX)

Unlike many other repos, we invite story telling, design, persona development, context setting... This repo is actually much more UX / Design focused than many other work items, because persona and fictional organization development are a feature of great design.

  1. How are you involving participants from various global locations in this work item? (Americas, Euro, Asia-Pacific, South America)

Collaboration on github is async.

  1. How do you plan to involve non-technical subject matter experts & end users of your work item? How will you work item improve their lives?

How will the W3C CCG attract these folks to calls? We'll be sharing this work with other communities, but people need to know about it too decide to contribute. This work item would be helpful for folks just starting to learn about DIDs and VCs.

(this question should be split up).

  1. What actions are you taking to make this work item accessible to a non-technical audience?

Inviting contribution on github is about as good as we can do for now, not sure if that implies a failure here, but we don't have any additional bandwidth to manage contribution outside of github.

Feedback on questions

There are way to many of them and many are semi-redundant.

I would boil them down to:

What are you trying to do? Articulate your objectives using absolutely no jargon. How is it done today, and what are the limits of current practice? How are you involving participants from multiple skill sets in this work item? (technical, design, product, marketing, anthropological, UX) If you are successful, what difference will it make? What are the risks?

Notes on process

GitHub is a barrier to entry, but other tools are a burden for collaborators... IMO this is a thing the W3C CCG needs to address, not a thing members are responsible for.... W3C CCG should run sessions on fostering collaboration from non technical stakeholders in GitHub, not ask each work item contributor to take on this burden / address it in a different (potentially very expensive) way.... work item contributors should be asked to show up to those sessions and address:

How are you involving participants from multiple skill sets in this work item? (technical, design, product, marketing, anthropological, UX)

At regular intervals.

Thats all the feedback for now.

cc @w3c-ccg/chairs

vsnt commented 3 years ago

Great feedback @OR13. Thank you for going through the questions. And yes, I agree there are too many of them. It may be good to address your comment about github barrier/comfortability in the CCG 101 work item. It's an interesting suggestion to have a "board" (for lack of a better term) to review work items on a regular basis...

OR13 commented 3 years ago

I have moved the repo / setup the boilerplate: https://github.com/w3c-ccg/did.actor

Please close this issue once you have confirmed it is setup correctly.

kimdhamilton commented 3 years ago

@OR13 I updated the github org in a few places: https://github.com/w3c-ccg/did.actor/pull/3/files

I kept the did.actor site info because it appears to be redirecting (I see the CNAME file is there), so I suppose we can keep that

kimdhamilton commented 3 years ago

People/permissions added and added to work_items list. @OR13 this should be good to go; you can merge PR any time