- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Tue, 1 Aug 2017 16:42:20 +0100
- To: public-credentials@w3.org
Please accept my apologies for today's meeting as I am travelling David On 31/07/2017 17:40, msporny@digitalbazaar.com wrote: > Thanks to Nathan George for scribing this week! The minutes > for this week's Credentials CG telecon are now available: > > http://w3c.github.io/vctf/meetings/2017-07-25/ > > Full text of the discussion follows for W3C archival purposes. > Audio from the meeting is available as well (link provided below). > > ---------------------------------------------------------------- > Credentials CG Telecon Minutes for 2017-07-25 > > Agenda: > https://lists.w3.org/Archives/Public/public-credentials/2017Jul/0028.html > Topics: > 1. Re-Introductions > 2. Action Items > 3. DID Specification Work Item > 4. Lifecycle Deep Dive > Resolutions: > 1. Accept the DID Specification as a Credentials CG work item. > Organizer: > Kim Hamilton Duffy and Christopher Allen > Scribe: > Nathan George > Present: > Nathan George, Chris Webber, Christopher Allen, Dave Longley, > Ryan Grant, Manu Sporny, Drummond Reed, Joe Andrieu, Adrian > Gropper, Moses Ma, Frederico Sportini, David Chadwick, David I. > Lehn, Adam Migus > Audio: > http://w3c.github.io/vctf/meetings/2017-07-25/audio.ogg > > > Topic: Re-Introductions > > Nathan George is scribing. > Chris Webber: I work on social web stuff, and am absentmindedly > participating and lurking in the background to hear what is going > on > Christopher Allen: Thank you and welcome > ... is there any longer term member that would like to > reintroduce themselves to the Credentials community > Dave Longley: I am the CTO of Digital Bazaar, we create products > related to Web Payments, Verifiable Claims, and Blockchain - we > co-founded this group and a number of others at W3C. We build our > solutions on open standards and devote a lot of time to > initiatives such as this one. > > Topic: Action Items > > Christopher Allen: On work items, our oldest work item is the > naming options > Christopher Allen: > https://lists.w3.org/Archives/Public/public-credentials/2017Jul/0026.html > ... we've decided at this point to pursue this proposal in this > email > ... which is to leave the name alone for now, but we haven't > called that final in case there are any objections > ... none have been raised on the list, we have until next > meeting to do so > ... the plan is to keep the name the same and change the > charter to address the things we wish to address > ... the revision of the mission statement will begin in August > ... There will be a proposal about how to work with the Digital > Verification group > ... are there any action items we have missed? > ... nothing being raised in queue > > Topic: DID Specification Work Item > > Christopher Allen: The next discussion is to officially take on > the DID as a work item > ... we have many champions implementing it, and no objections > so far > Manu Sporny: https://opencreds.github.io/did-spec/ > Ryan Grant: +1 > ... question for manu, can we do this with "+1" here? or do we > need to do it on the list? > ... or do the chairs just say yes? > Manu Sporny: Typically W3C process is to seek consensus and > chairs only step in if that cannot be achieved > Manu Sporny: Typically w3c process is to try to achieve > consensus and let that drive it, only when it's difficult to find > consensus do the chairs step in. I would suggest that we do a > quick call for consensus on the call today and see how many > people we have supporting it. After we do that, notify the > mailing list that there's a week to object to taking the DID spec > as a work item. [scribe assist by Dave Longley] > ... lets do a quick +1 on the call, and then notify the mailing > list that there is a week to object. If there are no objections, > then we'll proceed. > Drummond Reed: Who makes the proposal? > Manu Sporny: So lets see how much support there is here, and > notify immediately to the mailing list > Manu Sporny: If there are no objections after a week we just > pull it in and start working on it. That's the typical way to > address addition of new work, it results in the hardest thing to > undo after you work on it. I think we should propose to work on > it in the CG right now and then make an announcement immediately > after the call on the mailing list notifying about objections for > a week. [scribe assist by Dave Longley] > Manu Sporny: That's the typical process. [scribe assist by Dave > Longley] > > PROPOSAL: Accept the DID Specification as a Credentials CG work > item. > > Christopher Allen: The proposal is to accept the DID data > specification that has been drafted by Drummond, Manu and many > others as a work item > ... please +1 or -1 that here > Manu Sporny: +1 > Drummond Reed: +1 > Joe Andrieu: +1 For DID as a work item > Christopher Allen: +1 > Dave Longley: +1 > Nathan George: +1 > Adrian Gropper: +1 > Moses Ma: +1 > Frederico Sportini: +1 > Ryan Grant: +1 > Christopher Allen: We have 9 votes in favor and no objections > ... I will post an email to the list right after the call > ... Moving on to our main topic of a deep dive > > RESOLUTION: Accept the DID Specification as a Credentials CG work > item. > > Topic: Lifecycle Deep Dive > > ... We discovered that multiple participants have interest in > the life cycle of a VC > ... but different approaches to how to look at that, that may > be very compatible > ... each will take a 10 minutes to describe how they approach > it, then some time for them to comment on similarities, and then > open things up to a group discussion > Joe Andrieu: My presentation: > http://legreq.com/files/WoT.VC.EngagementModel.pdf Joram 1.0.0: > http://bit.ly/joram100 Chris's WoT Scenario: > https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/RWOT-User-Story.md > Joe Andrieu: Here are some links, one for the presentation then > the Joram paper, then Chris' work to frame the use case > ... my work item was to propose doing a identity life cycle and > engagement model with VCs > ... the Joram 1.0.0 paper came from the Syrian refugee crisis > research > ... the idea is to capture the human requirements on both sides > of a complex technical systme > ... for Joram we assume there is a magical distributed data > store and that Joram can accrete an identity through that system, > but try not to get bogged down in the specifics of how that works > ... we added some devops stages, I'll get to this in a second > ... it covers all the stages of user engagement with the system > ... the idea is to keep it slim and easy to read, as a > sympathetic narrative so that you can get into the minds of the > users > ... and understand why they are doing what they are doing and > get a gut-check of the viability of the system (would they really > do this?) > ... the fourth slide is all 15 stages all together > ... in slide 5 the two paragraphs that comprise stage 7 > ... show the level of detail involved. > ... (see content) > ... this gives you a sense of what people need to do to > accomplish their jobs > ... on slide 6, the top half of the stages > ... describes how things unfold > ... <continues to outline stages in the > joram-engagement-model.pdf file> > ... Identity information is acquired through stage 6, > disclosure > ... stage 9, updates, covers expected changes to the record > through some sort of interface or app > ... in step 10 things are going wrong in an unexpected way (you > might have to hand-write some sort of edit to the DB) > ... step 11-13 are devops stages > ... transferring one schema to another are covered. > ... finally how to deal with lost credentials, which might be > the hardest problem in this type of use case > ... after that exit and re-engagement > ... slide 8 is a link to ChristopherA's work, a write up of a > "web of trust" use case involving first and second generation > emmigrant trying to establish a reputation that doesn't > compromise personal safety or current workplace location > ... that wraps up the introduction to this model > Drummond Reed: Great stuff, Joe > David Chadwick: > https://drive.google.com/file/d/0B2qPJBxhjfdqYmJGaE5HODFLZ3ROUFAxQ05yOG9uRTBaaDlr/view > Moses Ma: How do I get on the queue? > Christopher Allen: We will go to questions in a couple of > minutes, next up DavidC > David Chadwick: I've put up a link to the doc I have published. > There is some overlap, but JoeAndrieu' > ... 's approach is a bit different > ... I've started from a new born baby > ... when someone is born there isn't any information about them > yet, and it has to be created by who we call "issuers" in the VC > model > ... Issuers create and store information about individuals > ... it is naturally distributed because there are hundereds of > entities issuing this information > ... and it gets stale, and needs to be updated > ... when it is stale they may delete it, the person may come > back and ask to have it updated, and there is an issue here in > the world today > ... insofar that there is a very weak binding between the > person and the information that is held about them > ... so it sometimes only requires as little information as your > address to pose as someone else and get that information changed > ... one hope is that VCs create a stronger binding that will > prevent someone from claiming to be you and using that to steal > your information > ... take a look at page 2 and that the information is about you > but you're not necessarily creating it or owning > ... that information > ... we do want you to be able to control who can see it > ... The holder is moving to the center of the ecosystem, and > controlling access even when they are not the issuer > ... You can create your own information and issue information > about yourself (favorite food or color) > ... However we are most interested in claims created by others > ... this information will always be created or held in some > form by the Issuer > ... then this information will need to be updated > ... there is no fool-proof link that binds the person to the > information, but we'd like to make that much stronger > ... There are three cases here we might want to consider > ... starting fresh with a new identity, come with the identity > from the country of origin, or masquerade as another person > ... this is not the core of what we're looking at, but this > model could apply to what JoeAndrieu discussed > David Chadwick: The figure here was published by the group 6 mo > or a year ago > ... we are on page 5 > ... this shows the Holder as the center of the ecosystem and > how they hold them and present them where they wish > ... there could be use cases where someone other than the > subject holds and presents, but I think that is an unusual case, > not the normal case > ... there are 9 steps outlined here as the life-cycle of a > Verifiable Credential > ... Finally I look at the trust model, which is very important. > ... without this we can't say much about these > ... a R.P. needs to be able to know what to trust and how to > use the data > ... <see bullet points> > ... The issuer and inspectors do not need to trust the > repository, which is a critical difference between this and > federated identity management > ... we might want the user to trust the repository to not lose > information and not corrupt data > Drummond Reed: Indeed, that's a big difference > ... so the question now is how to relate this document to > JoeAndrieu's > ... in his he is interacting with Stewards and the user just > has a bracelet identifying him to those Stewards > Ryan Grant: Okay here > Christopher Allen: I'm calling back. > Joe Andrieu: Chris did we lose you? We could hear David > ... perhaps it is good to see what questions we have now about > similarities and differences > Christopher Allen: I'm back, did DavidC finish > Manu Sporny: Yes, we can start processing the queue at this > point > Christopher Allen: JoeAndrieu, first would you like to comment > briefly, and then a turn for DavidC before we go to the queue > Joe Andrieu: One interesting thing (I like the work here on > fleshing out the whole picture), the data model is really focused > on a single individual, but doesn't discuss merrits or things > like a trust model > ... that isn't in scope for my document > ... it is just one thread through the experience > ... It didn't start out as intentional, but the information > life-cycle is not about identity but focuses on information flows > instead > ... where that information "acretes an identity" > David Chadwick: I saw the main difference was that JoeAndrieu's > model has the stewards doing the interaction with the data store, > and the refugee is a passive entity > ... but wasn't the main actor > Christopher Allen: The web-of-trust use case has a lot more > "agency" items addressed, so that may help > Manu Sporny: There are two points I'd like to make > ... I'm trying to figure out where all of this good work goes > from a document perspective > ... how do we direct that energy into the specfication or > architecture for the W3C standards track > ... we want this stuff to become more central to the messaging > than just a published doc > ... David's work feels like a big improvement on the > architecture document that we have right now > ... and it feels like we could take section 2 on of this > document and make that into the VC arch doc > ... the architecture document could have some life-cycle > documents in it, or some life-cycle explaination > ... then we could point to JoeAndrieu's work > ... as it does a great job of breaking down the whole use case > in a technology agnostic way > ... which helps us call out what technologies we are mapping > these use cases to > ... JoeAndrieu, how do we intend to map this to a set of > technologies to achieve the use case? > ... this could provide good gap analysis to see if we've > covered it > Christopher Allen: (I do map in my draft of the WOT user story, > but I don't think Joe plans to keep that part) > ... DavidC, would you be comfortable with putting this into the > arch document and pointing to JoeAndrieu's detailed use case in > there? > ... which then JoeAndrieu could map to which specs help to > achieve is use case? > Moses Ma: I think what we'd like to do is take what you've done > and create, maybe not a use case for the entire group, but map > the needs for an ICO investor > ... they are doing to want to know "is this a hacker?", "is > this an accredited investor?" and this might help us understand > the other end of use (as opposed to the refugee case) > Ryan Grant: I have a question for JoeAndrieu > ... on the center of the pictoral diagram, that is a sort of > state of rest, is there a name for it? > Joe Andrieu: This is a visual short hand to keep from having the > arrows go to all the other places > ... every arrow that goes there goes out to all the other > connections > Christopher Allen: I think it marks that timeline is different > than the previous which has discrete steps > ... for example once you've disclosed you could go into any of > the other stages > Ryan Grant: So apart from the one-way's that are called out, it > is just a way of reducing the arrows? > Joe Andrieu: Correct > Ryan Grant: I have a question for DavidC for the way to search > for disputes by the subject of the claim > ... for example, they believe I live in Hawaii but have also > given me a good credit rating > ... causing the dillema, do I use it when it is obviously not > quite correct? Can I somehow register my formal dispute, that I > have attempted to correct my data? > Moses Ma: Joe, Manu, Chris - do you want us to create another > "user persona" diagram? We can map the day in a life into a > single visual. > ... it would be nice to have some way of registering these > David Chadwick: This is a good question, where the Issuer is the > owner of the information and publish incorrect information about > you > ... I'd like to think that the data protection legislation that > we have would help with this (legally providing the ability to > redress this) > ... I know that there are supposed to be ways for addressing > this > Moses Ma: I mean modifying the current diagram to fit this use > case, integrating the models presented. > ... I have used the legislation to pay to get the data but not > change it > ... I think it needs to go into the model somewhere, it needs > to be able to be addressed > Ryan Grant: I feel like we do have these legal means, but where > there is an agent-mediated protocol it makes bumping out of that > mediated protocol very difficult > ... it creates many registration and complexity issues > David Chadwick: The hope is that you as the center have the > ability to control this, but there are some interesting impacts > to this, where you may chose not to disclose negative information > about you > ... so we need means for someone being able to disclose > information to an inspector without necessarily involving the > Holder > Christopher Allen: Clearly there are a few things in this > category > ... a discussion in the VC group about kinds of VCs, including > providing evidence of ratings or reputation > ... then the difference between revocation (by the issuer) and > refutation (by the subject) > ... some of this belongs in the data model, some of it in the > layer above that > ... in our community there is a difference between a > self-sovereign system and how you might do this in other ways > ... the self-soveriegn approach doesn't necesaarily address > negative information but does address other concerns that are > underrepresented currently > ... Another thing that really helps is that these documents are > consicse and we need more documents like them > ... something about a user with agency over their healthcare, > for example going through the life-cycle of care > ... we should come up for a name for what these are called > where they are not quite use-cases and not quite user stories > ... when I designed the web-of-trust bitcoin reference, I > referred to Alice's engagement model to make sure we had the > right steps outlined in detail > Joe Andrieu: I would like to respond to Manu's question > ... How do we map this work to tech implementations? > ... For what we're doing with Alice, there is the assumption > that it is the technology we are doing for VCs > ... with Issuers, Holders and Verifiers and how that works, but > I probably won't drive down more than that > ... those are design and implementation choices > Moses Ma: By the way, it looks like our consulting firm is going > to get a gig with a large bank to facilitate a design spec around > blockchains, decentralized identity, verifiable claims and... > capital markets. If you'd like to join the design sprint as a > "spark plug" outside innovator, please send me an email with your > bio. It won't pay a bundle, but we'll be able to cover travel and > an honorarium. My email is moses.ma@futurelabconsulting.com. > Probably in late September. > ... It is easier to place a design decision in the narrative, > but when you tease out the non-human interactions you free up > what the implementation _can_ be > Manu Sporny: Thanks, that is good > David Chadwick: Also to answer Manu's question, I'm happy for > that to go into the working document > ... I can work with you offline on the mechanics of edit > rights, etc > Adrian Gropper: This leads me to ask, is this too simple a model > for self-soveriegn identity in the following sense: > ... in the HIE of one we have a practitioner who isn't an > institution and a patient, Alice > ... they have technology to manage their self-soveriegnty > Ryan Grant: (FDA) > ... with mobile devices and identity containers, and I'm not > sure that the two presentations today capture that "three layer > model" that includes the pharmacy or DEA as the institutional > component > David Chadwick: I'd love to read your use case and see if we can > have it fit when it is finished > Adrian Gropper: I'm in process writing an update for RWoT in the > fall > David Chadwick: Please post a link > Christopher Allen: One of the key things here has to do with > "agency" > ... Joram 1.1 should be more specific about agency and who is > in control at various phases > ... whether it is institutions or Joram himself > Moses Ma: Nage, the ICO example would include the SEC or (France > AMF) and the dealer broker, so it might capture the three layer > model. > ... Alice, Bob, and Carol have 100% agence, etc > ... we might have a third party like an insurer where there is > less agency... > ... given the engagement model how might we do this through a > variety of mechanisms > ... in all of these documents capturing these details might be > important > ... JoeAndrieu and DavidC and agropper and whoever else, please > continue to evolve these and see how this information might fit > in > ... to answer manu's question, I don't think we're quite there > for integration, but we should encourage them and keep them > moving forward (I plan to particpate) > Christopher Allen: Next week we will close out the naming > discussion and start on the mission statement > ... that will be about half of the meeting, are there any other > requests for next week? > Joe Andrieu: Want to talk after the call about "apartment > hunting" use case? [scribe assist by Ryan Grant] > ... if you have any more to present please let us know > Moses Ma: One other small issue - "VC" is very established as an > acronym for "venture capitalist", maybe discuss expanding to a 3 > letter acronym? > Adrian Gropper: Can someone help find my HIE of One RWoT link > before the minutes are closed? > Ryan Grant: Moses: +1 > ... the final thing that we are going to do is "if there those > that would like to hang around for DID discussion" > Christopher Allen: We'll want some time for DID issue discussion > on next week's call [scribe assist by Drummond Reed] > ... we will take a few minutes after the meeting for the next > few weeks for a "stand up" of sorts around that topic > ... thanks for joining us, we will have another call next week > > > > >
Received on Tuesday, 1 August 2017 15:42:50 UTC