The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


Credentials CG Telecon

Minutes for 2017-07-25

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
... 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
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
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