W3C home > Mailing lists > Public > public-credentials@w3.org > July 2017

[MINUTES] W3C Credentials CG Call - 2017-07-25 12pm ET

From: <msporny@digitalbazaar.com>
Date: Mon, 31 Jul 2017 12:40:08 -0400
Message-Id: <1501519208774.0.27321@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Nathan George for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


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

  1. Re-Introductions
  2. Action Items
  3. DID Specification Work Item
  4. Lifecycle Deep Dive
  1. Accept the DID Specification as a Credentials CG work item.
  Kim Hamilton Duffy and Christopher Allen
  Nathan George
  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

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 
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: 
  ... we've decided at this point to pursue this proposal in this 
  ... 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 

PROPOSAL:  Accept the DID Specification as a Credentials CG work 

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 

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: 
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 
  ... 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 
  ... 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, 
  ... 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: 
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 
  ... 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 
  ... 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 
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 
  ... 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 
  ... 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 
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 
  ... 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 
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 
Christopher Allen:  Clearly there are a few things in this 
  ... 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 
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 
David Chadwick:  Please post a link
Christopher Allen:  One of the key things here has to do with 
  ... 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 
  ... 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 
  ... JoeAndrieu and DavidC and agropper and whoever else, please 
  continue to evolve these and see how this information might fit 
  ... 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 Monday, 31 July 2017 16:40:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:44 UTC