Coder Social home page Coder Social logo

did-use-cases's Introduction

W3C Logo

Decentralized Identifier Use Cases v1.0

This is the repository of the W3C’s note on Decentralized Identifier Use Cases v1.0, developed by the DID Working Group. The editors’ draft of the specification can also be read directly.

Work on this document has now been completed with publication of the Use Cases and Requirements as a Working Group Note on 17th March 2021.

Contributing to the Repository

Use the standard fork, branch, and pull request workflow to propose changes to the specification. Please make branch names informative—by including the issue or bug number for example.

Editorial changes that improve the readability of the spec or correct spelling or grammatical mistakes are welcome.

Please read CONTRIBUTING.md, about licensing contributions.

Code of Conduct

W3C functions under a code of conduct.

DID Working Group Repositories

did-use-cases's People

Contributors

brentzundel avatar davidlehn avatar iherman avatar jandrieu avatar kimdhamilton avatar or13 avatar peacekeeper avatar philarcher avatar plehegar avatar rhiaro avatar tallted avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

did-use-cases's Issues

New Use Case Proposal: Blending DIDs with X.509

Blending existing X.509 certificates with DIDs enables faster adoption while using existing trust anchors

There are two ways to integrate DIDs with X.509:
image

Use case will describe how the relation between DID and X.509 can be established.

Describe relationship between DID Methods and DID Authentication in Use Cases document

There isn't a clear description of the relationship between DID Methods and the DID Authentication process in the Use Cases document. Is the DID Authentication process entirely DID Method specific? If not, is it possible to describe what parts of DID Authentication are and are not method-specific?

Also not made clear is the role of DID Methods in DID Resolution. (Part of this might be productively covered in the terminology section #12.)

While this may seem like basic stuff to those who have been developing these specs for a while, we owe it to readers and developers to make these relationships clear. Knowing these things would help readers better understand the way that DIDs are intended to operate.

I'd also be interested in opinions what parts of these explanations belong in the Use Cases document versus which parts of them belong in (or also belong in) the DID Core spec.

No reference for "the DID Resolution specification"

Section 3.5 (Resolve) talks about "the DID Resolution specification" being under development but doesn't supply a reference to it. (I'd also thought that DID Resolution was likely method-specific, and so there wouldn't be a single DID Resolution specification.)

Please clarify in the Use Cases document.

Add human story for 2.1 online shopper

Rather than just presenting generalities, I'd like to consider adding or simply using something like the following for the use case currently known as 2.1 Online Shopping

2.1 Online product verification
Merry has been seeking a special edition, collectible card ever since her best friend, Eli, opined about losing the one his Dad had given him as a reward for getting straight "A"s in 4th grade. She found it on an online marketplace, for sale by DeepVintage in another country, over 2000 miles away. Although the marketplace promises refunds, Merry is also worried that Eli's heart would be broken if she accidentally got him a fake.

Fortunately, DeepVintage is able to provide documentation in the form of signed statements of title transfer from each of the owners, all the way back to the original, which includes a statement of authenticity from the original manufacturer. Each of the signed statements can be independently verified because they were signed using public DIDs for the buyer and seller. The collected signatures comprise a complete chain of custody along with some interesting anecdotes about each sale. Merry was able to verify the provenance of the card and delighted Eli with a surprise gift of a perfect replacement for his lost memento.

DID CRUD is a confusing term

I am reading the Use Case document while attempting to write a document that explains DID to people with a limited technical background.

Section 3 "DID Actions" is helpful, but I am confused by the introductory diagram and paragraph about "DID CRUD". I believe this attempts to group all actions into one of 4 categories and the diagram is supposed to explain to the reader where each of the actions described in section 3 falls. I think it would be much clearer to the reader to have subheadings explaining this.

(@jandrieu might recognize my attempts to kill all complicated diagrams from previous experiences working with me ). If the diagram remains, the alt text is not sufficient. It confused me, and I have no vision issues.

Title of the document

The charter refers to the "use cases and requirements". In light of that we should probably rename the document accordingly.

Jargon from VCDM and crypto

There is A LOT of jargon in this document that comes from the Verifiable Claims Data Model and will be incomprehensible to a layperson. (verifiable credential, issuer, etc). Likewise, there is the assumption that the reader knows enough about cryptography to make sense of terms like "pairwise-pseudonymous". There is a delicate balance between writing use cases that define the spec and writing use cases that convince people who are not yet adopters that they should be. I find the focal use cases especially difficult to parse.

What does it mean for a DID to be "recorded in a registry"?

3.1 Create says that "These DIDs are recorded in a registry...". But there's isn't a clear explanation of what it means for the DID to be recorded, or what properties a registry has.

For instance, using database terminology, if the registry is a database, what consistency and/or atomicity and durability properties of the database entries are assumed and are necessary?

I suspect there's a lot behind these few words that bears fleshing out.

Add human story for 2.1 Vehicle assemblies

Rather than just presenting generalities, I'd like to consider adding or simply using something like the following for the use case currently known as 2.2 Vehicle Assemblies

2.2 Vehicles and assemblies
When Bertha bought her new car, it came with its own DID, not just as an alternative VIN, but with unique DIDs for every replaceable component in the vehicle and a secure data storage for keeping track of vehicle use and maintenance. Even before she purchased it, she was able to verify that, as advertised, every part in the car is 100% made with carbon-neutral processes.

As the controller of the car's DID, she had automatic control over all of its component's DIDs. During maintenance, she would choose mechanics that automatically provided digital records of their work, stored at her direction in the car's data store. When a part needed to be replaced, she'd make sure the new component's DID is recorded and the old one retired. Similarly, her car automatically tracked fuel purchases and saved telemetry reports to storage, where it was kept securely under her control.

She found an insurance company that was able to automatically offer her a discount after passing a certification of good maintenance and good driving. When she later put her car up for sale, she was able to prove her track record of maintenance. Upon sale, she transferred control over the car's DID and its secure storage, giving the new owner a working, and contiguous record of the vehicle.

Add Focal Use-Case for human-centered DID interoperability: Alice Rents a Car

Our service endpoint and interop discussions will benefit from a human-centered perspective. To that end, I've invented a hypothetical badge, the Gold Button, that indicates interoperability between one's authentication and authorization agent and various service providers. The Gold Button is conceived as a voluntary assertion to a standardized bundle of protocols, TBD, that is NOT domain-specific. In other words, the idea is that the auth'n and auth'z agent asserting Gold Button is general while the competing service providers asserting Gold Button are typically domain-specific (e.g. healthcare or education).

Here is the proposed additional focal use-case:

Alice Rents a Car

Background

It’s 2021 and SSI is the golden child. Alice looks forward to never having to use a password or fill out a form again. Alice’s service providers are looking to adopt zero-trust architecture with Y2K zeal. Neither of them really know what SSI or zero-trust means, but they want it.

Description

Alice has just provisioned an “agent” as recommended by EFF and supported through Mozilla. It’s costing her $5/month and is somehow linked to the FaceID that also unlocks her smartphone. Her agent occasionally sends a text message asking a question with a yes or no answer but otherwise mostly leaves her alone. Her agent bears a Gold Button logo that she thinks is a bit like “American Express welcome here” in the old days.

Alice is going to France. She uses DuckDuckGo to discover a list of car rental companies anonymously to avoid price discrimiantion and targeted ads. Some of the rental companies display the Gold Button logo, some don’t. She knows that the ones that do will respect her agent. She picks Fertz for the rental even though she has never done business with them before, knowing that with Gold Button her user experience will be an automated breeze.

Among dozens of others, Alice already has Gold Button service providers for her US driver’s license, her US insurance, and her bank. The DMV, insurer, and bank all authenticate Alice using a secure pseudonym linked to her smartphone. Each of the three has a different DID for Alice, but each of the three knows that they can use that DID in court to hold Alice accountable. Alice just knows that her smartphone allowed her to sign her driver’s license application, her insurance application, and her bank customer registration form using FaceID because Gold Button works.

Alice clicks on the Fertz “Rent Now” button and:

  • Exposes a DID through her agent in order to set up a secure communication channel.
  • Fertz tells Alice’s agent that they will need license, insurance, and bank info for the purpose of renting a car in France.
  • Alice’s agent has a policy that saying that any company as large as Fertz can get whatever they explicitly ask for. Smaller companies, or large ones on a blacklist may need Alice to give explicit permission - which the agent will ask for using a text message.
  • Alice’s agent gives gives Fertz three signed bearer tokens authorizing release of her personal information from three specific service providers. These tokens are encrypted so that Fertz doesn’t know what’s in them. Alice’s service providers use pre-registered information linked to their DID for Alice to decrypt the tokens and verify they were signed by Alice’s agent.
  • Note, that in this example, Alice does not care that her three service providers know she is becoming a Fertz customer. If Alice did care, she might go through the trouble of having one or another of the services issue a Verified Credential to her so she can present it wherever she wants. Alice’s agent has policies that force the more privacy preserving, Holder-mediated flow when dealing with some less trusted vendors.
  • Fertz gathers the information from Alice’s service providers, checks it against their internal rental policies, and issues Alice’s agent a signed capability linked to a QR code. The agent emails the capability to Alice.

The whole sequence from click in the search results to Alice getting a QR code in the email took 8 seconds. A week later:

  • Alice goes to the Fertz garage at Charles de Gaulle airport, and picks a car with the keys already in it and the price posted on the parking space. She drives to the automated exit gate.
  • At the gate, Alice opens her email, shows the QR code she received through her agent and gets a message on her phone asking her to scan her face. The gate agent combines the license info of the car, the QR code and the challenge signed by Alice with her face and opens the gate.

Challenges

The challenge in this case is to combine technical standards and protocols into a human-meaningful interoperability claim that crosses between one's general-purpose agent and a multitude of domain-specific service offerings.

Distinction

This use case is based on a profiling exercise by a group to be determined and the voluntary adoption of the badge by some agents and some service providers. The badge need not be associated with a costly certification process which means that both audited and un-audited versions of the claim can co-exist. False and misleading assertions are already enforced by both the marketplace and by truth in labeling laws.

Add use case for DIDs+eIDAS

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

Background statement in Decentralized Corporate Identifiers description not obvious

Section 7.1.1 (Background) says "A great number of business to business and business to customer transactions could be executed more quickly and with greater assurance of the validity of the transaction if a mechanism to self-issue cryptographic identifiers were created." It's not clear why this actually true. The premise behind this assertion could use a more thorough description.

Synchronize DID role terminology between Use Cases and Core specs

Section 2 of the Use Cases (What can you do with a DID?) defines three entities for working with DIDs: The Controller, the Relying Party, and the Subject. This seems highly related to w3c/did-core#4 - which is about defining terms for three DID roles.

The terms for these roles should be kept in sync between the specifications as they evolve.

General comment on the document structure

(I presume this was the subject of discussions in the CCG days so, maybe, I am just reigniting buried discussions. But I am a new kid on the block...)

I am puzzled by the current structure of the document. It reads like an introduction to DID and some sort of a post-decision justification of why DID are defined. This is not the goal of such a document in my view. According to the charter, what we are supposed to publish is a "use cases and requirements" document (although the title does not say that): what this should mean is to have general requirements (independently of DIDs!) and show that the technology we have chosen does fulfill at least a majority of those requirements. This is not the way the document reads today.

The good news is that, I believe, the information is mostly there, so I am just looking for a reorganization of the document. If I was to reorganize it, here is, roughly, what I would do:

  1. A set of use cases. This is, essentially, section 7
  2. A number of requirements that can be deduced from the use cases. This is sections 4 & 5 (which are together the focal point of the whole document for me), although I would probably invert the sequence, start with section 5 and summarize it in using the table of section 4
  3. A section on showing how the requirements bind to the use cases, which is, essentially, section 6.

In some sense, we could actually stop there: the fact that DID does fulfill the majority of the requirements, and how, is, logically, a different (albeit necessary!) document. But we can decide to include, in the same document, some sort of a Part II:

  1. High level view of DID, essentially section 2
  2. More details on what DIDs are; this is section 3, although, if we do publish some sort of a DID Primer, than that may be the better place
  3. Showing how DID does respond (or not) to the requirements listed in the required features by showing how those requirements can be mapped, technically, onto a DID-based infrastructure. As far as I can see this is not (yet?) part of the current document, and we must, at some point, provide that.

At least for me this would make this document much more useful...

When do we publish a FPWD of the Use Cases document?

As described in w3c/did-core#68 (comment) , our charter https://www.w3.org/2019/09/did-wg-charter.html states that we are producing a Use Cases document defining requirements that the DID specification is intended to meet. Having the Use Cases document is therefore necessary to be able to evaluate the DID specification.

I believe that we should consequently be reviewing and stabilizing the Use Cases document with the same vigor that we are the technical specification, and in the same timeframe.

Focal use cases: more emphasis on DID-s?

The title of the issue may be surprising, but reading the focal use cases I wonder whether these are use cases for Verifiable Credentials or for Decentralized Identifiers. In many cases (e.g., in §7.1 and §7.2) I have the impression that it is more the former than the latter.

I realize it is not always clear to separate the two, but the texts should nevertheless be revised to make it much clearer where the behaviour of DID-s come into play as opposed to emphasize the role of credentials.

Term 'Relying party'

The term 'relying party' is under discussion and does not yet have the WG's consensus.

Relying Party terminology could confuse things

A decentralized system will enable several key actions by three distinct entities: the Controller, the Relying Party, and the Subject.

We hit an issue with "Relying Party" in the Verifiable Credentials Working Group. That is special (highly specific) terminology in existing standards and I'm concerned that we don't mean the same thing here than what is expressed in current standards:

https://en.wikipedia.org/wiki/Relying_party

I suggest that we steer clear from that terminology and use a new term, or one that's broader than what's linked to above. I'm wondering if we can re-use verifier from the Verifiable Credentials spec..

Tiny (mostly editorial) comments.

  • §2.1: "Online shopping, especially including 3rd party marketplaces creates" probably needs a comma after "marketplaces"

  • §3, first paragraph: "...as intended in the DID Working Group Charter." refers to the time when the charter was still coming up. Maybe worth rephrasing this...

  • §3.3 " DID is in fact its controller or specified as a Controller for a particular service endpoint. " I presume the first occurrence of "controller" should also capitalized (and possibly linked back to the terminology section?)

  • §3.3 "allow for separate, proofs": isn't the comma superfluous?

  • §3.4 " later be verified (#7 Signature Verification)" I presume the reference is to §3.7; not clear from the text

  • §3.6 "When a DID is combined with a service parameter (forming a DID URL), dereferencing returns the resource pointed to from the named service endpoint, which was discovered by resolving the DID to its DID Document and looking up the endpoint by name....": this seems to be way too much details for a UCR document (and I am not sure the text in the paragraph is clear either...)

    I also have to say that the difference between §3.5 Resolve and §3.6 Dereference is not really clear in the text. The usual idea associated with a 'dereference' sounds the same as what is called 'resolve' here (Dereferencing a URL means that I get to the HTML file whose address it is). I think I understand the difference but the text needs some clarification imho.

  • §3.19 "controllers": should be capitalized and referenced to the terminology (I may have missed some other, typical cases in the section, better check...)

  • §4. introductory paragraph: I miss some form of a forward reference to the focal use cases. Reading the document so far there is only one use case, and a vague reference to "In collecting and evaluating potential use cases" and the feature/benefit grid comes a bit out of the blue. It may be useful to make it clear that this is some sort of synthesis, backed up by the focal use cases that are meant to be the representative use cases for the feature/benefit grid.

    Jumping ahead a bit, I also wonder whether the order of §6 and §7 should not be inverted. I read the document, get to the grid, I want to read the use cases and then I can understand what §6 wants to say. Getting to §6 before the focal use cases is fairly unclear.

Decentralized Identities are simply Credentials and should be defined/called out as such...

A Decentralized Identity is simply a Credential and should be defined/called out as such. That is, a Decentralized Identity is simply a (Verifiable) Credential associated with a Subject by a Decentralized Identifier. ...a Credential being a collection of Claims (name-value pairs) associated, again, with the Subject by a Decentralized Identifier.

This clarification is important because it leads to a natural partitioning of the actions one performs against a Decentralized Identity in comparison to those actions that are generic to a Credential (e.g. creation) and those that are specific to a Decentralized Identity.

Confusion about what a "DID" is throughout the document [DID Credentials]

In https://www.w3.org/TR/did-use-cases/#concepts-of-decentralized-identity, the text somewhat correctly defines what a DID is:

A globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology (DLT) or other form of decentralized network. The generic format of a DID is defined in this specification. A specific DID scheme is defined in a DID method specification.

The majority of the rest of the document starts defining concepts like "DID Actions" ...which are not actions on a DID, the identifier, as defined in the above section of the document.

There is a total mismatch here between a DID being a Decentralized Identifier and a DID not being a Decentralized Identity, i.e. a Credential consisting of a collection of Claims associated with a Subject by a Decentralized Identity.

ACTION: Need to separate out the actions against a Decentralized Identifier (a character string) vs. against a Decentralized Identity (a Credential).

New Use Case Proposals: 1) FMCG Intelligent Serial Number, 2) VIN DID, 3)Circular Economy

DID as Intelligent Serial Number for FMCG objects (digital twinning), /Vehicles and Objects in the Circular Economy - DID cyber-physically linked to a product

  1. FMCG Object Intelligent Serial Number (FMCG = Fast Moving Consumer Product)
  2. VIN DID (VIN = Vehicle Identity Number), i.e. DID for your Car
  3. Item Circular Economy (this is my preferred crown jewel use case of DIDs, because in a circular economy it is unpredictable which human or algorithm needs to interact with the circular item, to resolve the URL and to validate the life-cycle history of the object)

Questions to be answered:

  • How to establish a DID for an object such as a Fast Moving Consumer Good
  • How to establish a vehicle DID in the human world (i.e. private key controlled by humans) as the Manufacturing Order is created to ensure back-to-birth traceability.
  • How to link the public key sitting in a vehicle telematics box as signing key to the DID document controlled by humans? Now the telematics box can do data attestation on behalf of the human controlled DID of the vehicle, Example of VIN DID (i.d. DID for Vehicle Identity Number)
  • How to establish a cyber-physical link (recipe)?
  • What is behind the service endpoint? Credential Store, Business Service Agent
  • Short Value Proposition and new business use cases of Intelligent Serial Number for businesses
  • Item in Circular Economy as further extension of the FMCG object digital twin

I will condense the content that is written here:

https://medium.com/spherity/ssi201-upgrading-products-with-intelligent-serial-numbers-and-dids-78da623b91dd

Long-life, recipient-managed credentials example doesn't say how the recipient can validate the issuer of the diploma

Section 7.2 (Description) assumes that the recipient of the diploma data structure has a way of validating that Oxford was the issuer of the diploma, but doesn't say how that would be possible in practice, especially when Oxford could cease operation, lose accreditation, or be impersonated by another "Oxford".

It's also not clear what value using a DID is providing in this example, beyond carrying the diploma data structure signed by Oxford.

Again, this may seem like obvious stuff to those of you who have been living and breathing these specs for a while, but the actual description at least didn't make these things obvious to me, when I reviewed the spec.

Use Cases document missing References section

There's a number of places in the Use Cases document that refer to other specifications without providing references to them. First, a References section needs to be added. Then entries in it need to be filled in and used when the spec alludes to other documents such a "DID Resolution" specification and a "DID Auth" specification.

rename master branch

Summary

We should rename the branch master to main and use that going forward for our work.

From Problematic Terminology in Open-Source on master/slave terminology in software:

Use of this term is problematic. It references slavery to convey meaning about the relationship between two entities.

Removing this terminology from our workflow is a small gesture to include more people from marginalized groups in this project.

(I’m open to names other than main)

Technical Steps

  • create main branch from master
  • make main the default GitHub branch
  • modify github/central to use main for release notes reloading
  • redirect PRs to main in w3c/did-use-cases
  • move branch protections from master to main
  • modify docs to reference main instead of master
  • delete master branch to avoid confusion?

Feedback?

Use Case Pile-up

This is probably a shipment of coals addressed to Newcastle, but the use-case freewrite I did in Barcelona at RWoT well-nigh a year ago never got finalized through the RWoT editorial process, although I did make a slightly more schematic version here:
http://www.caballerojuan.com/assets/static/publishing_chapter_sovrin_book_(graphics_tbd).pdf

If any of the little paragraph-long use cases would be helpful to rework and conform a little more to the format of the rest here, pop me an email or a message through github and I will try to find an hour this week/end to edit it into a proposal to be section 7.6 and another row in the chart in section 6. Out of curiosity (and I'm still willing to contribute regardless of the answer), are the contributors to this crowdsourced addition to the document listed anywhere, or are they only visible in the git trail?

Suggestion: Better partitioning of "DID" actions

In section https://www.w3.org/TR/did-use-cases/#actions of the document, it partitions the entire lifecycle about a "DID" (it's confused definition) into five categories: C.R.U.D. plus Use.

UPDATED: My suggestion is that it would be more useful to partition the collection of actions into a first category of those actions that essentially involve single role/actor and a DID Credential (defined here #57 (comment)) ...that is, simple operations like C.R.U.D. on a single DID Credential associated with single role/actor. These are primary actions related to a single role/actor. These actions are of interest to implementors and users of DID repositories/registries.

CORRECTED: The remaining actions (the second category) are those that involve the communication and verification of DID Credentials between two or more parties. These actions are of interest to implementers and users involved with DID communication protocols and verification protocols that are implemented on top of the DID Credential repository/registry actions.

CORRECTED: The current organization (and associated diagram) is confusing for the above reason as well as the confusion in the overall document about what a DID is: a Decentralized Identifier (i.e. an string identifier) or Decentralized Identity (i.e. a Credential) . You need to pick just one of these.

Terminology section issues

The fact of sharing the terminology section with the core spec does have some, possibly unwanted, consequences with references that are not relevant in the UCR document. As an example, it now says "The generic format of a DID is defined in this specification." I am sure there more. I guess what this means is that the language of the common terminology section should be revised to abide by the requirements of both documents.

However, there are elements that will remain no matter what:

  • From the use case document's perspective, this section contains way too much details. I do not think any of the use cases really make use of, say, DID fragments, DID query, etc. and this presents further hurdles for the non-expert reader
  • the terminology should to include terms that the general reader may not know. For example, I must admit that, before joining this WG, I did not know the term "rotating" as used in the crypto world and a terminology entry would help. The same holds for, e.g., "pairwise-pseudonymous" and probably some others.

I must admit I am beginning to question the wisdom of sharing the terminology section. The audience of the two documents are fundamentally different, and these discrepancies show it...

"Surveillance capitalism" terminology?

(Term used as no. 8 of the required features.)

I do not think it is appropriate to use this term. "Surveillance" is not bound to "capitalism"; other societies, past and present, have or had a practice of surveillance (alas!). In my view, the term "surveillance" should suffice.

Clarify intent behind he language "When a DID contains a service name"

Section 3.6 (Dereference) uses the language "When a DID contains a service name". I believe that what's actually said is closer to the meaning "When a DID is accompanied by a service name parameter". I know that there's a distinction between the base DID and parameters that can be added to it.

To the extent that this ability part of enabling Use Cases, this distinction should be clearly explained in the Use Case document.

Auto-inclusion of glossary from DID-Core

The current UCR automatically includes the terminology section from the DID-Core, which seemed like a good idea at the time. However, this text, not unreasonably given its provenance, includes phrases like "The generic format of a DID is defined in this specification" which are inappropriate in the UCR. Therefore I think the terminology section should be replaced with a simplified, static, version with words to the effect of "this is how we use these terms in this doc. Definitions may be updated in the DID-Core spec (link) in which case the definitions provided there should be seen as authoritative outside the specific context of this use cases document."

Language usage in the use cases

I must admit I had some difficulties reading the Use Cases themselves (i.e., section 7). Part of it is simply the language and terminology used: the text uses a very dense language, with references, terms, etc, that are not necessarily clear outside of the US. It makes it difficult to follow for non-native English speakers. (I know it is very difficult to pinpoint the issues precisely...)

Using such very English (or American? I wouldn't know) terms and situations like "sticky wicket", "downstream customer", "estate planning", "probate authority" should definitely be avoided or, if necessary, explained. An example of US-orientedness is 7.3: the very notion of separate "planned parenthood clinics" is not a general term in, e.g., Europe or Asia, and the name does not make it clear that these clinics may also treat issues like UTI (which is not necessarily related to "parenthood"). Let alone the fact that I, for example, have never heard of the fact that you can make an online diagnose of anything leading to prescription (I do not think something like that would be possible where I live).

Also, these use cases are not specifications: they do not have to be perfectly precise. Using terms like "cryptographically authenticate", "such as firmware hashes and checksums", "self-management of identifiers and cryptographic key material,", "pairwise-pseudonymous", "rotating keys" are mixing use cases and requirements with the solution, and that should not be the goal of the document. It also makes it very difficult to read, mainly for someone who wants to understand what requirements led to DIDs and does not arrive with the full knowledge of crypto and all the other niceties...

Use Cases document missing Terminology section

The Use Cases document defines and uses a number of terms, but there's no Terminology section to systematically capture the definitions introduced. Please add it and populate it.

One term that belongs in the Terminology section is "DID registry". Another is "DID Method", as well as "DID Controller", "DID Subject", "Relying Party", and probably "DID" itself.

Decentralised Identity Resolution

Hi,

I was wondering if the member of this group have given any thought to how identity resolution could work under this model, and if yes what is what are the key challenges and blockers.

With the demise of 3rd party cookies, many web publishers would be interested in how one can share opted in information about users across domains.

Is this a use case which you feel fits within the concept of DIDs?

Best,
Dennis

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.