The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2019-06-11

Drummond Reed is scribing.
Bill Barnhill: +Present
Introductions: Isaac works with Bloom (sp?) that works with verifiable credentials and DIDs

Topic: Introductions and Re-introductions

Joe Andrieu: Rohan pinto
Rohan Pinto - 1Kosmos
Reintroductions: Rohan Pinto did a re-introduction

Topic: Announcements and Reminders

We also have Mike Engle - 1Kosmos on the call as well.
Kim Hamilton Duffy:
Kim Hamilton Duffy: Dedicated DID calls are 1-2:30PM Pacific Time on Thursdays.
Clear here, listening over phone
Kim Hamilton Duffy: 2. #RebootingWebOfTrust IX Prague — September 3-6th
Kim Hamilton Duffy: 1. Https://
TPAC 2019 - Sept 16-20 in Japan.
Dan Burnett: Will be at TPAC.
Joe Andrieu: Asked Markus about a pre-meetup in Vienna
Amy Guy: Anyone then roadtripping from vienna to prague?
Markus Sabadello: Yes, he is planning on a pre-meetup in Vienna prior to Prague, two days early. The first day will be Sept 1.
Kim Hamilton Duffy: Asked about TPAC because the chairs have an overdue action item about booking space. Need to find out who is going. Brent Zendel from Evernym and Ken Ebert from Sovrin will be going.
Dan Burnett: If the DID WG is created before TPAC, then there will be a meeting there.
Kim Hamilton Duffy: For upcoming meeting agendas, the announcement page should have details. Waiting for completion of DID calls.
...if there is any topic you want to see on the agenda, reach out to the chairs.
...first issue is uncompleted work items a first work item candidate, the chairs would be happy to provide mentorship suggestions
...for #79, Kim is going to call on Manu
...Manu sent a message about 83 non-testable normative statements in the DID spec
...Kim would like to figure out what our next steps are.
Manu Sporny: The good news is that Andrew Jones has started on a DID test suite.

Topic: Action Items

...he is starting early because "it bit us" with the verifiable credentials spec will verify if a DID is in the correct syntax, and whether a DID document is valid
...identified 26 normative statements in the DID spec
...but also identified 83 normative statements that are not testable
...normative statements may or may not be testable. Many companies will ask for non-testable normative statements to be removed.
...non-normative statements break down into a multiple categories.
...normative statements about what a DID method specification must do can be human-testable.
...those are okay to keep; may want to consolidate
...others are more suggestive, such as recommending that a DID registry should not be centralized.
...Manu suggests that we should remove any of those statements that will chew up a bunch of time to discuss.
...the third class is normative statements that are clearly untestable, either by a machine or a human being.
...the email that was sent to the list was just a heads-up about the count of the various normative statements.
Kim Hamilton Duffy: Wanted to see if there was any followup we need to be doing. Any other suggestions?
Markus Sabadello: Asked about use of uppercase MUST vs. lowercase must
Markus Sabadello: Open PR about lower case / upper case "must", "should", etc:
Joe Andrieu: : Wants to talk about new Rubrics Task Force
Manu Sporny: Lowercase must/should/may is not normative. Uppercase are normative, especially MUSTs. SHOULDs are sometimes tested. MAYs are almost never tested.
...sometime people don't notice the difference of using the capital format. sometimes language changes make it clearer that the requirement is not meant to be tested.
...secondly, about what we can do, Manu suggests we go ahead and let the DID calls complete.
ACTION: create an github issue against DID spec. Spreadsheet, mark ones people want to keep as normative
...we may need to create a Google doc and then mark the ones that people want to keep normative to reduce the 83 number to something that's more feasible, like 20.

Topic: Rubrics Task Force

Joe Andrieu: At the last DID call, it was agreed to create an informal task force to agree on the scope of the Rubrics work, and to kick it off.
...Joe doesn't have a time yet, so it may not be next week, but calls will start soon.
Joe Andrieu: Re : rubrics task force, email me at if you want to join the calls
Kim Hamilton Duffy: Next topic is the registry meta-topic.
...we have some ongoing work items; registries is one of those.
...Manu introduced a process whereby any group can create a registry.
...If we want to suggest our process as the best way to do this, what do we do?
Christopher Allen: Some WGs are facing time limits, and must finish on time, but after they are done, they often have leftover items like registries.
...the CCG is a logical place to do that, and has agreed to.
...there is a Process Group at the W3C that decides about such things.
...this group has discussed "evergreen working groups" that have been chartered to be continual
...Christopher asked that group about registries
...Some members of the Process Group felt it was appropriate, others felt that it should be a separate process
...their meetings are 7AM ET, so Christopher hoped that someone else could monitor/work on this.
...that said, the CCG still doesn't have our own registry process worked out

Topic: Credential CG Work Item Process Draft, simplified

Kim Hamilton Duffy: 2. Https://
Manu Sporny: Soooo much better! :)
Kim Hamilton Duffy: Hopes that people find this much simpler
...wants to start with the work item process that applies to any work item effort in the CCG.
...Kim hopes the state diagram is clear - it's a 40,000 foot view
...the adoption process is how the supporter finds support in the CCG
Manu Sporny: I think this should be proposed as the default W3C CG process for groups larger than 10 active participants.
...once there's been discussion for at least a week, and there are no objections, and it is covered under the charter, then it is adopted. it an ongoing community draft (such as a registry), then it will just keep going until it is closed after a period of inactivity.
...the other type is a finite work project. It will be closed either when completed or after inactivity.
...ongoing community drafts (like registries) and community report drafts (like specific docs).
...conformance test suite is another type of ongoing project. reports drafts have several subtypes. A draft spec (e.g., DID spec), a community note (e.g., DID Primer).
...notes would not go on to a WG but a spec might.
...moving to 20,000 foot view
...within those two types of projects, what is their process.
...there is a well-known process for community notes as shown in the doc
...rough draft, unreleased draft, release draft (when the editors tag a release in the repo), final release draft
...any of these can exit early some examples as of May 29 2019
...DID method registry -- intended to be an ongoing thing
...DID Primer is a community note. Currently in an unreleased phase.
...further along in the process is the DID spec—a community draft
Christopher Allen: The DID spec is a published draft
Kim Hamilton Duffy: Hopes this diagram helps clarify these things
...particularly if we add links to the deeper parts
...this is still a lot to know. Hopefully this is only needed by some people, such as chairs.
...It is designed to help broaden inclusion and identify areas where we can make it easier the community report draft stage, it moves into another stage when it moves to github
...for other types of community reports, it's been fairly natural for a lot of the iteration to happen in less technical tools like Google docs
...that would make it easier and more accessible
Drummond Reed: +1 To enable as much work in Google docs (or the equivalent) as possible
Dmitiz: Asks about a subprocess for something in a registry, such as the did:web: method.
Kim Hamilton Duffy: That might be a community report depends on how the registries deal with it
Christopher Allen: There are 2 issues here. One is the registry change. the first one is just acceptance in the registry.
...then the second question is whether the particular DID method will be a CCG work item.
...if not, it would be in a separate non-CCG repo. But if it's going to be a CCG work item, then it goes through the process.
Dmitri Zagidulin: For specs that want to be part of the CCG umbrella—that want a spec and repo under CCG—they go through the community report side of the workflow.
Kim Hamilton Duffy: The chairs will be coaching some new items through the process.
Manu Sporny: We have heard enough people complain that the github process is exclusionary—and even the tech spec have large swaths that are just text... anything we can do to transition the editing cycle to Google docs or similar for as long as possible before the final stage, it will help gain more input.
...this is something we should probably work on
Kim Hamilton Duffy: I have good news on that
...we could really use help polishing off that tool chain will have a very positive impact
Kim Hamilton Duffy: Bill Barnhill has been looking into that
...this is absolutely one of the critical pieces to help make the process more inclusive
Christopher Allen: Until the tooling is better, there's nothing that prevents a work item from going from unreleased to final report quickly, i.e., from a Google doc into the final Respec form in a repo.
...that process could happen in a week, and have a version number attached, and it gets published.
...the final step of turning it into an official report might take a little longer.
Kim Hamilton Duffy: Thanks for calling that out.
...that early stage can work in another form like Google doc and the team can get paired with someone who knows github. the following weeks we are going through work item repair (but we won't get to them today)
Bill Barnhill: I’ll report on issue 76 next week.
Amy Guy: +1 TallTed !!
Ted Thibodeau: Is frustrated with the way the discussion is going. Surprised that this group is advocating Google docs as a tool.
...also, Google docs does not have a good way of doing document comparison. space is available on both W3C servers and github servers, and offer features that are not in Google docs.
Kim Hamilton Duffy: Acknowledged that "Google docs" has just been a placeholder for "another easier collaboration tool than github".
...invites anyone else to suggest a tool.
Joe Andrieu: Yes, thank you, Jonathan
Joe Andrieu: We should put that in the process
Manu Sporny: Has the same issues with putting everything in Google. Suggests we just look at an editor as a tool, and suggests that we export as often as every day.
Ted Thibodeau: Export to....?
...a second point is that we're using Github which is now owned by Microsoft.
Ted Thibodeau: Github == Microsoft, yes ...
Ted Thibodeau: W3 wiki ?
...the goal is to find an easier way for people to contribute. there are ways to solve this.
...unfortunately W3C wiki has not been very easy for many people.
Ted Thibodeau: You have to jump through "some hoops".
Kim Hamilton Duffy: Must close the call due to time.
Heather Vescent: Commenting here, that github is not user friendly for non-technical people, which is a major problem re: inclusion. Not sure I understand why google docs is a problem. Haven't seen that detailed in the notes. (Am not on phone)
Ted Thibodeau: Heathervescent - most significantly, change tracking/viewing has been a major challenge in past work on Gdocs. (That may have improved; Gdocs *is* a constantly moving A-B-testing target.)
Amy Guy: I think we're significantly less 'locked in' to github/microsoft since we own the underlying data through git
Dmitri Zagidulin: I'd be happy to find a non-google-doc alternative that has a good annotation / sidebar comments functionality
Amy Guy: If google decided to take away all our docs overnight, even if we had exported them, we can't reconstruct that environment
Amy Guy: Ugh yes dmitriz I agree, need to see how nextcloud is doing
Heather Vescent: @Tallted, if you use suggest changes, it makes it super easy to collaborate with many people
Ted Thibodeau: Heathervescent (others) - Can you pick two arbitrary versions to compare? (This has been a key feature of wiki-based work in the past, both for reverting changes and for saying "you're doing great at this, can you do more?")
Ted Thibodeau: Yes, google docs lets you do that [scribe assist by Dmitri Zagidulin]
Heather Vescent: TallTed - not sure. I tend to do collaboration with the parties directly. There is less need to reconcile versions because everyone is always "on the same page"
Dmitri Zagidulin: View revision history, and pick two arbitrary versions
Heather Vescent: Vs editing MS word asyncronously.
Amy Guy: Personally I'd be grumpy about being required to blanket agree to Google's terms of service in order to contribute to anythiing
Dmitri Zagidulin: Or wait.. possibly that feature was removed...
Heather Vescent: I think it comes down to level of comfort. As a writer, I am power user for Google Docs. The other writing tools I use are not collaborative. Github makes me super cranky when people try to make it fit with writing. It is not a writing tool and no real author would ever use github to author anything.
Ted Thibodeau: Dmitriz - "revision history" is dimmed on the file menu for the doc we were just viewing ... which may be because I'm a suggester, not an editor... or may be because Google is playing A-B games ... or may be because they broke something, or took it away.
Dmitri Zagidulin: Yeah, could be a permission thing
Dmitri Zagidulin: Anyways though, I think we just need to draw up a list of required features for an alternative.
Dmitri Zagidulin: And see if any other sw supports it
Benjamin Young: Maybe try or similar
Ted Thibodeau: A code manager is challenging for prose management. Wikis are often better
Ted Thibodeau: Heathervescent - *live* collaboration is a different ballgame, to me. Asynch collaboration is far more typical, and (in my experience) far easier when working with larger groups -- because while you're all on the same scroll, Joe may be on "page" 12, while you're on "page" 27, and I'm on "page" 53 -- and each of us may be making contradictory edits to those areas.
Ted Thibodeau: The "live save" model means that each word-level or even character-level change is a version -- and you can have interspersed edits by each of those users -- so comparisons are even harder to figure out.
Ted Thibodeau: This is another reason why wiki page-save or git pull-request changes are better in larger, more asynchronous group efforts.
Amy Guy: From my reading of the google ToS ( google has a right to use any content we provide for promotion of google services, use it in any google product other than the one you upload it to for other reasons that what you provided it for, and the license continues even after you stop using the service
Amy Guy: Hopefully they don't find a way to use DID stuff to promote google services though ;)
Ted Thibodeau: Just wait for the new G-DIDs "10% project" to surface...