- From: Joe Andrieu <joe@joeandrieu.com>
- Date: Sun, 03 Jun 2018 13:00:00 -0700
- To: public-credentials@w3.org
- Message-Id: <1528056000.1498970.1394910664.78C98952@webmail.messagingengine.com>
On Sat, Jun 2, 2018, at 9:27 PM, Jordan, John CITZ:EX wrote: > So, thanks Manu .. as I wrote that email I recognized the use case > didn't specifically say only one DID / organization as you point out > below .. however it is good if we are specific about that NOT being > the case as there are many that still think this way as it seems > "natural".> > I think I understand that we need use cases for the W3C process (I'm > new to that process) ... what is a bit fuzzy to me is that DIDs are > probably not something the people will be normally exposed to in their > day to day digital interactions. It is sort of like IP addresses > (except many per person and not geo located of course!) in that DIDs > are addresses and they are for machines. Should the use cases be a bit > more low level in that they could describe the types of peer to peer > connections they enable, the ability to have verifiable credentials > issued to them, and so forth. Having the DID addressable layer is 100% > critical to the goals of being able to exchange trustworthy bits but > they are a little under the covers. For better or worse, there isn't a definitive "W3C Use Case" template or process. "Use cases" in the W3C sense are the preferred mechanism for demonstrating the value proposition of proposed standards; however, every use case document I've seen does it a little differently. In ours, we are building on the work I did with the VCWG and the Verifiable Credentials use case document [1]. That is currently going through a major revision, where the "Focal Use Case" is how we do a deeper dive on key use cases that illustrate in some detail the human requirements driving the technical decisions. My approach to use cases--and hence the approach I'm leading with to get these written up for the chartering process--is to seek use cases that illustrate* value-creating *interactions with a system, as far ahead of technology design & implementation decisions as possible. For example, in the domain of ATMs, "entering a PIN code" or "inserting card" are not, in and of themselves, value creating and they embed design choices. A few common ATM use cases that do create value are: o Withdraw cash o Check balance o Transfer balance It is possible to describe how each of these use cases occur with minimal reliance on implementation choices. For example, you don't need to mention a screen, keypad, card & reader, and a PIN. Instead, you can talk about presenting options, identifying the correct account, inputting the amount, authenticating the user, and authorizing the withdrawal / balance check / balance transfer. This type of essential representation allows downstream implementers to innovate how each particular use case is satisfied, for example by using voice or biometrics instead of a screen and card reader. So, ideally, a good use case will illustrate that *because of DIDs* individuals get uniquely valuable transactions with specific systems, described with minimal reliance on the underlying tech. This will help us understand the human requirements independent of the solution designed to meet those requirements. If it is clearer to write it up with the design choices, start there; we can tease out the most relevant bits. I encourage you to focus on the human experience that is enabled by DIDs rather than the underlying mechanisms or protocols, except where they MUST be described to illustrate the use case. My Joram paper from RWOT [2] has several examples where we distilled the human experience with minimal dependence on the technology. The use case should describe *why* a use is uniquely valuable to real people and *what* the persons involved do in their interactions, but not *how* the technology does it. The latter part is the work of the technical specification. The use cases should tell the tale of why DIDs are different and valuable, independent of downstream design & implementation choices. They should explain why people will value DIDs-- even, or perhaps especially--when they have no idea what's going on under the hood. To wit re: IP addresses: while IP addresses are generally hidden from most users most of the time, they are vital to how the Internet works. Key use cases that drove the development of IP were about network users being able to maintain connectivity in the face of catastrophic failure of particular servers on the network. What matters isn't how NATs or switches or address blocks work, but rather that under distress (the loss of components in the network), the rest of the network is able to re-route and to the end user, "it just works". In any case, I'll be working with use case authors to flesh out their submissions. Hopefully that helps. [1] https://w3c.github.io/vc-use-cases/ [2] https://bit.ly/joram100 > > I like the characterization of "single long lived identifier / single > entity" ... I may borrow that if that is ok (> > Best > J > > > On 2018-06-02, 11:33 AM, "Manu Sporny" > <msporny@digitalbazaar.com> wrote:> > On 06/01/2018 03:37 PM, Jordan, John CITZ:EX wrote: > > I don’t think we need a single identifier like we have been > > trying to> > unsuccessfully have in some places for years. I feel like those> > numbers are a bad side effect of centralized database primary > > keys.> > Agreed. > > > I think the reason I am quite resistant to a single identifier > > (if> > that is what is being contemplated) for an organization is that > > in> > the real world stuff happens. > > It was not what was being contemplated nor proposed, but I can > see how> one could interpret the use case as such, so we should make it > clear> that organizations/entities are expected to have more than one > DID.> > I said an "Organization gets a DID"... that doesn't mean its the > /only> DID/ the organization has. > > This group has identified the "single long lived identifier / > single> entity" (e.g. SSN, DUNS, email address for identification) design > as a> privacy concern in the VC spec here: > > https://w3c.github.io/vc-data-model/#identifier-based-correlation> > and here: > > https://w3c.github.io/vc-data-model/#long-lived-identifier-based-correlation> > We list the "desirable ecosystem characteristics" that we want > here:> > https://w3c.github.io/vc-data-model/#use-cases-and-requirements > > So the change that needs to be made to the Decentralized Corporate> Identifiers use case is: > > Clarify that organizations will have more than one DID, typically > scoped> appropriately to the interactions that they will perform using the > DID.> > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu > Sporny)> Founder/CEO - Digital Bazaar, Inc. > blog: The State of W3C Web Payments in 2017 > http://manu.sporny.org/2017/w3c-web-payments/ > > > -- Joe Andrieu, PMP joe@joeandrieu.com +1(805)705-8651 http://blog.joeandrieu.com
Received on Sunday, 3 June 2018 20:00:27 UTC