... IIW, which is April 30-May 2 in Mountain View, CA.
... Seen quite a few emails on the VCW email list. Might be doing verifiable creds meetup right after rebooting.
Joe Andrieu: Definitely going to do it. 4th and 5th, Monday and Tuesday after RWoT, will be face-to-face for verifiable claims working group, open to members and guests. Contact the chairs of that group to ask for an invitation. Limited number. Reach out to Dan Burnett or Matt Stone. ✪
Dan Burnett: Sent an email to CCG list last week announcing the meeting. Reply to that if interested. ✪
Topic: Progress on Action Items
Kim Hamilton Duffy: Doing this a little differently. A few process issues to clean up. In general, we are going to do ... reviews to ID unlabeled items, but we're skipping those. ✪
Dave Longley: Tightening up implementations of LD proof and DIDs, taking into consideration community input around terminology. Email sent to mailing list with terminology specifics. Effectively, a number of terms used in the community and into proofs and DID documents, such as cryptographic suites, creator and owner, are debatable. Considering changing because they cause confusion. Given some alternative names for terminology, taking into account what people ✪
Have been discussing. Some issues in the tracker for some of these. Main issue is stopping the use of 'owner', changing to 'controller'. ✪
Jarlath O'Carroll: FYI - currently having issues connection to conference phone line, anyone else? ✪
... While working on changes, adopted 'controller' instead of 'owner', interested in getting that into the spec. Also talking about changing 'cryptographic suites'. Existing term of art that makes people think of something else.
... Other terms changed are replacing 'creator' with 'verification method'. Value of 'creator' field for signatures is ID of public key. Changing to 'verification method' makes more sense, allows to work toward making proofs more generic.
... Talked about a variety of different kinds of proofs, like biometrics, etc.
Manu Sporny: Correction --- privacy preserving biometrics ✪
... Change/adoption/suggestion: try to include a proof purpose. Helps tighten up use of proofs in the ecosystem. Ensure that proof is created to include a purpose, helps eliminate some edge cases.
... Create a proof for purpose of authentication, different than assertion. Don't want assertion data to be reused as authentication method.
... Authentication field in the DID spec which establishes a link between entity that controls, and verification methods. Entity can say that thes public keys are for authentication, or for assertions.
... Also covers case of object capabilities, where entity that controls can say that these are for invoking or delegating capabilities.
... In the email, details about linked data proofs work and how these elements tie together. Ensure that the verifier can make sure that proof was made for authorized purpose, using verification method authorized and matches the type of proof that was created.
... Terminology tries to be more specific about all of that. Would like feedback.
Kim Hamilton Duffy: Those are separate work items, broader changes affecting existing draft. Wanted to talk about that, see about feedback. ✪
... Check out the email and respond if any responses.
... Dont need to do the week waiting time because those will be PRs.
Manu Sporny: Definitely need feedback on this stuff sooner than later. Will discuss at Rebooting 8, but implementations are starting to put the stuff in. Should be where consensus is. ✪
... If anyone disagrees, let us know. Taken inputs from last two Rebootings, ..., hopefully people will be happy with changes, looking for one or two objections.
... If no objections, all changes will apply to next rev of DID spec, with data sweeps, etc.
... Implementations already exist to make sure it all works.
Kim Hamilton Duffy: Status to report on work or action items? ✪
Manu Sporny: Thanks to Michael Herman for issues raised on DID and VC spec, we will get to them, under work pressure to get verifiable credentials stuff going. ✪
... Have been watching issues raised, notice frustration in some of what is written. All good catches, need time to make changes in response over next couple of months.
Michael Herman: Where I'm headed on that. 36 issues added to DID spec, too many to review individually. ✪
... Will try to roll up in to a few main topics. If we can discuss those, then the details fall out in other issues.
... Indie arch. reference model is an important part of discussion. Work in progress, rolling up issues into smaller number of items.
Topic: Work Item Status Review
Kim Hamilton Duffy: Bulk of meeting will be talking about work item issues. ✪
... Starting off with mailing list topic from yesterday.
... Unclear state of work items. One reason is that we've not been crisp in communications about how to create new work items, and how to close work items.
... First one, we were being informal with description as opposed to pointing people to full details.
... Close work item process we're still working on, but as mentioned, want to address all the problems I saw to optimize for unblocking community, then on chairs to get rid of problems introduced.
... Most critical one is ... if you have a new item to propose, follow process to be describe. Main gap is that we haven't been identifying multiple owners. That's the main thing we had failed to do to kick off work items.
... Weren't following one-week countdown process, announce in CCG, announce in mailing list, wait a week for feedback.
... Thing that is critical for chairs to work on, highest pri, completing the closing work item process. Blocking closure of work items that are still pending.
... After we coplete that, start fleshing out work items that are all-but-done.
... Have a few blocked items, not in a clear state, chairs and owners will work together to figure out. Few other things, but those are most critical.
... Through combination of github templates and clearer pointers, hoping to avoid that in future.
... Want to show some updates (link above). Heavily redone, will be redone again. Main point is to understand what is the state, what do we have on these things, are there repos and drafts, etc.
... Calling attention to ToC, potential work items, talk about those and propose today.
... Next major section, current work items, see the registries and that's good at the moment.
... In that table, where you see status, in the W3 CCG process row, see that it is blocking others with footnote to more details.
... Blocing everything that says "needs close process." Quite a few that we think are almost there, but they need spec text, go through work item close process. Chairs need to work on that.
... Last major section is "completed work items." Goal is to capture closed work items. Can rethink structure later. Wanted to get information there.
... Some specifications incubated through this group, for example verifiable creds lifecycle, wanted to record that it's closed and integrated into verifiable creds data model.
... That's the overall structure. Can refer to this to see the current state of what's happening.
Kim Hamilton Duffy: Two aspects: one, talk about new process; next, overall process is in above link. Welcome comments. ✪
... Some uncertainties in close work item and other aspects of document, but confident of new work item process, which we'll talk about next. Focus on pushing through today.
Topic: New Work Items
Kim Hamilton Duffy: Walk through new work items process. Then start kickoff process work item topics that are ready. ✪
Kim Hamilton Duffy: Initial steps are standard. Create abstract or draft, like Google Doc or Github markdown page. Any way of capturing it. ✪
... Make sure there's a lead, person resonsible for advancing work item, and one other sponsor. Doesn't mean financial, but someone with skin in the game (editor, etc).
... Don't know if it's required that person is from a different company, but doesn't affect work items in progress now.
... Post a Github issue in the CCG org community repo, but don't create a CCG repo yet.
... Can create in personal Github account. Tag issue as proposed work item.
... Instead, creating Github issue templates. Some can be done through template, like tag, fields for owners, etc, to make it easier.
... Following, propose work item on weekly call and mailing list. Can do that in whatever order. Need both to happen before the one-week countdown start.
... One that Manu did. ... work item proposal, not that he has proposed work items label, editors, contributors, more than one.
... Already posted in mailing list, link with details of that.
... Already described this in CCG last week, doesn't have to go into as much depth as before. Starting one-week countdown for substantive objections to why we should do hash link here. Otherwise, formally accept, create Github repo.
Manu Sporny: When reading document, immediate reaction was "looks like a lot of process, preference to keep it light." ✪
... At the same time, has to be some kind of process.
... Hope is that chairs have tried to put as much process burden on selves, rather than on contributors.
... If people want to contribute, writing in email and sending to list should kick off process.
... Chairs will help guide people through that process.
... Issue template, like filling out a simple form in an issue tracker. Chairs take over from then on.
... Any thoughts on ease of use of process?
Kim Hamilton Duffy: Preference is for latter. Don't want usual thing every time, "get another owner, waiting period." Solve through automation. Figuring out what info we must have. ✪
... If can agree on that, add an issue template and just send the link to that.
... That way, anyone can be coached through proposal process through that template. Can ask for help, but we're busy people, want to minimize repeated info.
... Welcome to feedback.
Joe Andrieu: Respectfully do not want to put burden on chairs, already overwhelmed. ✪
... People create work items with community support. Bumped into different things getting that to engagable process.
... For issue #48, would be great to have real names of these guys.
... For editors and contributors.
... Not in the process to have handles.
... Have people who want to be part of team, but don't have Github handles, can't make them owners.
... Use Github/automation to streamline.
... Trying to create systems so operational burden is not on chairs.
Christopher Allen: Another aspect, chairs have to evaluate comunity support. Can't have work items waiting for a year on the list. ✪
... Better to put it on hold until there is interest. Can be on a private repo until more community support.
Kim Hamilton Duffy: Freezing queue on this topic at Ken ✪
... One step, I and other people will say, are we really ready to do this report?
Kim Hamilton Duffy: Any more comments, capture in CCG process document or some other forum. ✪
... Related note: thinking about automation for that. Every interest in making as useful as possible, but has been lingering work items with minimal traction.
Heather Vescent: Feels process is heavy, specifically for non-technical people. ✪
... May want to revisit process to simplify and streamline after feedback from survey.
Joe Andrieu: +1 For burden on non-technical folks; github is a challenge for many ✪
... Needs to serve the overall goals of what we're all trying to achieve. In some cases, if you are leading group and being one of people creating structure, that is an additional burden.
Joe Andrieu: ( I mean +1 in agreement, NOT +1 for actually having burden) ✪
... Someone to volunteer to manage?
... Feels like a lot of bureaucracy. Also doing this to support development of community. Could try it, get feedback on it, see how effective it is.
Drummond Reed: +1 To keeping the bureaucracy as minimal as possible ✪
Kim Hamilton Duffy: All we're talking about is "contract" (in an engineering sense). Know up front what we need, tell people in advance. ✪
... Easy to create automation to let that happen. Github templates, email path, etc. Getting content, making easier, we'll have both.
Ken Ebert: Whether we accept an item as a working item. Does that mean we expect to produce something, or is debate about whether we produce something after it goes on the queue? ✪
... Part of CCG process is saying, "What are valid forms of artifacts/results from work item?" Might be draft report, something less formal like position paper.
... One example: David Chadwick wrote up something, immediately into another spec.
Joe Andrieu: Trying to get process to be lightweight/streamlined from someone having an idea to closure. Have a chart made of clipart in the document that explains whre CCG work items might end up. ✪
... Piecing out details of how we keep on top of this.
... Mentioned in last call that we did not budget enough time for work item review, so want to streamline what's in calls.
... Only want to adopt work items that will get to closure, some don't, chair's job to move things along.
Kim Hamilton Duffy: Propose to kick off a few items. ✪
... Encoding in multihash that says what crypto hash was used to generate the hash. Multibase is same concept for base encoding.
... Binary data. Can't just put into an email, need to encode binary data using letters and numbers.
... Many ways of base encoding. Base 2, 8, 10, 16, 32, 64, 58, all ways to encode stuff.
... BTC uses base58
... Flickr uses base58, but their own flavor.
... Same for hexadecimal (lower or upper case?)
... Multibase is a way of encoding the base encoding. Can fit these two specs together, if you have a multihash expression in binary, can encode in multibase.
... Full forward and backward compat across crypto hashes and encoding schemes.
... More flexibility in encoding formats and crypto hashes in our systems.
... Would enable ... and Sovrin and IPFS to express certain primitives, like SHA256, in the same way.
... Can start building and using common libraries across Sovrin and IPFS.
Jonathan Holt: Lookup table is hardcoded in repo, is IETF to be source of truth? ✪
Manu Sporny: Eventually, yes, but for now, generated from Github repo. ✪
... Spec is generated from tables in Github, but will be a transition.
... Once that happens, IETF is very used to running registries - run hundreds. This is what they're used to, they have a process.
... Keeping spec text up to date is a PR.
... Next time we do publication, new spec text will be put in there.
Jonathan Holt: What's the turnaround time for that? ✪
Manu Sporny: Structure so that can be kept up to date. In multibase/hash, built where that's a fit. Simple spec, info in registry, updating registry is quick. ✪
... Turnaround is fast, PR can go in minutes, can have new version published at IETF in minutes until becomes RFC, after which, stability in specification.
... Builds on top of multibase and multihash. At last Rebooting, a few folks worked on a resource integrity proof, deployed into proofs of concept and pilots.
... Resource integrity proofs no longer the way to go, want to do hashlinks.
... Link has justification.
... Hashlink is a way of saying here's a proof and multiple implementations.
... Here's an item, an IPFS link, a BTC tx, etc. If resolver can resolve, then you've got a cross-network way of doing crypto linking. Important for JSON-LD contexts, Sovrin schema expression, items that Bodhan raised