DID Working Group F2F in Fukuoka — Second day — Minutes

– DRAFT Minutes –

Date: 2019-09-17

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Amy Guy, Kangchan Lee, Daniel Burnett, Brent Zundel, Manu Sporny, Pamela Dingle, Grant Noble, Markus Sabadello, Tobias Looker, Phil Archer, Dudley Collinson, Yancy Ribbens, Drummond Reed, Joe Andrieu, Michael Jones, David Ezell, Andrei Sambra, Kenneth Ebert, Helen Garneau

Regrets: Ivan Herman

Guests: Gregg Kellogg, Jay Kishigami, Kaz Ashimura, Arnaud Le Hors, Dan Brickley, Hadley Beeman, Michael McCool, Tara Whalen, Christine Runnenger

Chair: Daniel Burnett, brentzundel, Brent Zundel

Scribe(s): Kenneth Ebert, Markus Sabadello, Gregg Kellogg, Michael Jones

Content:

Brent Zundel: Review of agenda for today.
… We need scribes for later today.
… We will review resolution and other groups for joint sessions.
… Webex audio working?

Brent Zundel: See slides for the day

Ivan Herman: Yesterday’s minutes are ready as a draft. Please review the names and WG membership status.
… If you are missing please report errors back to me.

1. Test Suite

Brent Zundel: What are your thoughts about the test suite?

Manu Sporny: There is an existing test suite.

Manu Sporny: https://github.com/w3c-ccg/did-test-suite

Daniel Burnett: Manu will look up what is ready already.
… We need to decide when to do the work on it.
… It can be counter productive when we are still arguing about features.

Manu Sporny: example of test suite output: https://w3c.github.io/vc-test-suite/implementations/

Daniel Burnett: When we have set the features, then the test suite becomes critical.
… Are we at that point?

Gregg Kellogg: I follow Dan’s logic. But the biggest danger is that people we be afraid to tread.
… Tests take a high degree of effort. At the time changes are made if there is insight as to the implications.
… Perhaps a list of tests could accompany a PR to describe what needs to be tested would help.

Manu Sporny: Andrew Jones has implemented a test suite.
… In the VCWG we had a data model spec. It is similar to our DID spec. The VCWG test suite seemed to work.
… Examples:
… You create tests, and ask implementors to test their implementations against the tests.
… At the end we collect all the results into an implementation report.

Manu Sporny: https://w3c.github.io/vc-test-suite/implementations/

Manu Sporny: This is what an implementation report can look like.
… In the basic document section, “context must be…” and shows the number of implementations that pass a particular test.
… Checks and x’s show status.

Manu Sporny: https://github.com/w3c-ccg/did-test-suite/tree/add-tests

Manu Sporny: We have a similar thing for the DID WG already.

Manu Sporny: https://github.com/w3c-ccg/did-test-suite/tree/add-tests/test/latest

Manu Sporny: Andrew Jones added tests for the current DID spec.
… There are identifier and doc tests.
… Do we want to use this as a baseline?

Joe Andrieu: Thanks! We should build on it.
… Until the last CR, there is a possibility for changes. There is no single point when we know the spec is done.

Daniel Burnett: There is a requirement that when we enter CR, we must state the requirement for testing.
… A typical guideline is 2 implementors for each feature.
… To enter PR you must meet our stated requirements.
… We will have a test suite to enter Cr.

Markus Sabadello: We can expect some small changes, but the overall structure is fairly mature.
… Small changes can be made to the test suite as changes are made in the spec.

Michael Jones: While MS is not an official member yet, I like to make sure that is one clear way to do something.
… When I can I like to make things as simple as possible to enhance interoperability.
… If we have someone actively changing the suite, the is great.
… Markus said resolution is out of scope, so how can we fully test the rules?
… Although it is not in the scope of the spec, we could decide to include a resolution interop test.

Gregg Kellogg: I suggest that we have some instructions on how to run the test suite for implementors.
… Most implementors are more used to a data driven system.
… Data driven is easier than code drive.

Drummond Reed: I like Mike’s suggestion regarding resolution in the test suite.
… It is very useful to non-normatively cover this in the test suite.

Manu Sporny: Example of “How to run the test suite”: https://w3c.github.io/vc-test-suite/

Manu Sporny: Greg, instructions are here in the VC test suite.
… In the 8-10 implementations seemed to work.
… Input on stdin and output on stdout seemed to be simple enough.
… Using RDFa was more complicated.
… Mike and Drummond commented on resolution in the test suite.
… We excluded it from the spec because of potential objections to the charter if they were included.
… We added tests for optional tests for signature formats even though they were extensions.
… What DID method should we pick for testing?
… We wanted to avoid a political fight over it.
… Since then DID Peer and DID Key could be considered as a simple method type to test with.

Gregg Kellogg: perhaps a “test” method, defined with specific behavior for running tests.

Daniel Burnett: +1 manu to optional resolution tests, but we must not block group completion on disagreements around those tests

Manu Sporny: These would be optional tests.

Brent Zundel: I am pleased with the conversation so far.
… The questions we need to document and resolve are in these slides:

Ivan Herman: In other groups we had two or three implementations that accompanied the spec development.
… This provided valuable feedback along the way.
… It required acknowledgement of “changes will be required”

Markus Sabadello: With DID URLs, there is some functionality regarding selection of material from the DID document.
… This could be tested in a method-independent way.

Joe Andrieu: I would like to suggest that the method specific implementors should right the tests in an common framework.

Drummond Reed: In many ways it’s the method that needs to test things.
… Without resolution, all we can test the conformance to the DID ABNF and the contents of the DID doc.
… This would be the only two tests to perform under the charter.
… Peer DID or Key DID would be good alternatives.

Michael Jones: Test suites seem to succeed when there are committed developers who stay current with the spec.

Manu Sporny: Reminder that DID methods are out of scope for the charter. These increase scope creep.

Manu Sporny: Out of scope: “Specific DID Method specifications or Protocol specifications”

Manu Sporny: We have a little wiggle room.
… I agree with Mike regarding test suite developers.
… Digital bazaar is committing a developer to making updates every 6 weeks. It works better when there are other devs involved.

Phil Archer: We can’t look at resolution.
… The test suite as shown so far links directly to the implementation report.
… We need at least some resolution to create an implementation report.
… We built this thing that proves that the spec works.
… There is a difference between tests and implementations.

Gregg Kellogg: Are there requirements for defining a DID method that state what must be done?
… Can we specify test runner requirements, such as retrieval?

Daniel Burnett: With respect that we include that are optional because they are out of scope, if there is disagreement over them, I will have us take them out.
… How do you test a data model?
… What does that mean?
… All that is required is that producers and consumers stated what elements they are able to generate or consume.

Drummond Reed: Re: manu’s commitment regarding resources, Evernym is working on committing resources.

Manu Sporny: Optional tests regarding resolution, we have two independent resolvers.
… We can use them to demonstrate DID resolution and interop.
… The test suite is architected to callout to an implementation requesting an action with data.
… Example: verify that this is a valid DID or DID doc. The implementation performs the action on the data and reports success/failure.
… The is vague, but allows the implementation to do what it needs.d
… We could add other actions to the driver, such as create
… DID or verify DID.
… The test suite can handle it. Do we want to go there?

Drummond Reed: Can we propose to start with the current CCG test suite?

Manu Sporny: As Dan said, disagreement will result in removal of tests.

Ivan Herman: With regard to the DID doc, it is a json or json-ld document. It describes the vocabulary, not the actions.
… Some parts are only syntax. We must prove that multiple implementations use these terms.
… From a process point of view, we only have to prove this.
… It may be simpler from the charter point of view.
… Having more than the charter requires is beyond the minimal requirements.

Tobias Looker: I think the tests can be a forcing function to drive compatibility.
… I’m concerned about having another spec regarding resolvers, where are the boundaries between the DID spec and DID resolution?
… They may be valid but not pass the test suite.

Brent Zundel: DRAFT PROPOSAL: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.

Markus Sabadello: We are finding that the data model can be represented using other than json-ld.

Proposed resolution: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite. (Brent Zundel)

Manu Sporny: +1

Daniel Burnett: +1

Yancy Ribbens: +1

Joe Andrieu: +1

Drummond Reed: +1

Dudley Collinson: +1

Grant Noble: +1

Ivan Herman: +1

Markus Sabadello: +1

ken: +1

Brent Zundel: +1

Amy Guy: +1

Tobias Looker: +1

Resolution #1: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.

Drummond Reed: Thanks to Digital Bazaar for the work on the test suite.

Brent Zundel: We have other questions on the slide to review.

Daniel Burnett: If it looks like there is continuing and growing support within W3C, we could consider expanding the charter.
… We should not focus on this now, but it is a possibility.

Drummond Reed: +1 to this being something the WG should be open to considering.

Manu Sporny: Regarding Dan’s comment, yes the contention is reducing.
… Now is the time to work on the tests in my opinion. Let’s start now.
… I suggest that any method that is pure key method could be used. Either DID Peer or DID key would work well with low controversy.
… +1 to co-development of implementations.
… We are expecting each method to support their own tests.
… Pulling in all methods would be problematic.

Gregg Kellogg: +1 to manu’s points

Drummond Reed: -1 to the WG producing tests for DID methods with the possible exception of something like did:peer: or did:key:

Joe Andrieu: I agree with manu. I imagine that sov, btcr, etc. should write tests for the suite.
… I don’t think they should be included in the master suite.

Brent Zundel: I agree with manu’s thinking.

Drummond Reed: Does it make sense to recommend a method framework for the test suite?

Gregg Kellogg: I think we should have a single method, perhaps Peer DID or a subset of Peer DID.
… Also a scaffold for other methods with other plugins.

Drummond Reed: To put it different, I asked if the WG should recommend a test framework that DID method authors should use.

Gregg Kellogg: An interop fest might be key to demonstrate interop.

Manu Sporny: I think the existing test suite can do that.
… The driver calls actions.
… The actions could request the CRUD operations for the methods.
… Or you could call resolve() for the methods.
… The framework exists for Create() and read()
… You can also specify optional additional test suites.
… Each community can create its own tests.

Tobias Looker: Are non-normative tests using a specific method?

Drummond Reed: +1 to Manu’s description of what a test suite framework for DID methods would work—and even better that the current CCG test suite is already a start on that.

Tobias Looker: Some methods would be difficult to use in the complete set of tests.

Brent Zundel: We can’t create a DID method by the charter.
… We could use one or more to test.

Michael Jones: I second Brent’s statement.
… We should find a way to test the requirements using some implementations.
… I also want to support the idea that we are not creating a method, but it will be necessary to test resolution in order to facilitate the semantics.

Brent Zundel: Is there any controversy regarding how to pull in the test suite?

Manu Sporny: This is easier! Only Andrew has worked on it.
… It doesn’t matter. Let’s just use the W3C tooling to pull it over.

Brent Zundel: Does any one disagree with manu?

Gregg Kellogg: Are we going to copy it or move the repo?

Manu Sporny: There is not an IPR consideration here because only Andrew worked on it.
… We don’t care about the history as much.

Gregg Kellogg: The history would remain in the old repo.

Manu Sporny: I prefer transfer of repo, but multiple ways can work.
… What happens to the repos.

Ivan Herman: We archive the old repos.

Joe Andrieu: If we archive, can we redirect to the new repo.

Ivan Herman: Change the readme that says, “Go to the new repo”

Daniel Burnett: I don’t want to derail success, but in this case we could just move the repo. There is not a history concern here.
… Chairs and editors can work this out.

Manu Sporny:
… People don’t read. If we transfer the repo, people are automatically redirected.
… The archival approach has people not reading or html type links and google searches.
… It’s messier.

Gregg Kellogg: In json-ld we had this same problem. We changed the endpoint to autoredirect after a short pause.
… This worked well.

Proposed resolution: Ivan will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible. (Brent Zundel)

Manu Sporny: +1

Joe Andrieu: +1

Drummond Reed: +1

Daniel Burnett: +1

Dudley Collinson: +1

Kenneth Ebert: +1

Grant Noble: +1

Amy Guy: +1

Tobias Looker: +1

Yancy Ribbens: +1

Markus Sabadello: +1

Ivan Herman: I am not opposed. I don’t know if I have rights.

Proposed resolution: The DID WG will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible. (Brent Zundel)

Joe Andrieu: +1

Kenneth Ebert: +1

Brent Zundel: +1

Amy Guy: +1

Ivan Herman: +1

Daniel Burnett: +1

Dudley Collinson: +1

Drummond Reed: +1

Tobias Looker: +1

Grant Noble: +1

Manu Sporny: +0.9

Resolution #2: The DID WG will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.

Brent Zundel: We are done with this topic.

2. Logistics of additional meetings

Daniel Burnett: We live on a globe. The chairs will decide based on contributors and locations.
… There are problems with multiple calls. VCWG has an open slot.
… The CCG has resolution discussion time slot.
… There are times that are poor for everyone.
… I put out a doodle poll. I picked one day and put in all 24 hour slots.
… I’m only looking for Yes, No, If need be for the time of day.
… “if need be” is for occasional calls. Please be generous.
… We can collect other input as needed.

Brent Zundel: Link to doodle poll

Joe Andrieu: This is based on your laptop timezone.

Daniel Burnett: Please consider your own situation.
… More time?
… This is just input.
… This is biased. We need to consider other who are not here today.

Phil Archer: RE: Daylight savings time, we could adjust the meeting time.

Daniel Burnett: Grant and I have shifted our meetings times to handle that.
… There appear to be two main times. One is bad for Asia.
… I see few participants from Asia in the poll.
… The other slots are impossible for Europe.
… Specific individuals need to be considered.
… Who likes the current VCWG time?
… Who doesn’t like it?
… Who likes the DID resolution time?
… Who doesn’t like it?
… Kyle mentioned that he intends to do most of his work via email. We might be able to do 1 of 4 meetings at a time for him and others in NZ.
… Thanks for your input.
… Comments and suggestions?
… We haven’t considered which day yet?

Markus Sabadello: We need to continue to have a DID resolution call time also.

Daniel Burnett: I want a tradition of no meeting after F2F the week after.
… March would be a proposed time for the next F2F.
… Is that too soon or late?

Markus Sabadello: CCG’s DID Resolution call info is here: https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/ (but this can be changed to accommodate DIDWG call if needed)

Michael Jones: it is too late. We should try to meet in Jan after most technical issues are resolved by the end of the year.

Drummond Reed: +1 to January

Joe Andrieu: +1 to too late (January better)

Daniel Burnett: I have no objection to January. It is an interesting option.

Drummond Reed: +1 to January. We should have key issues lined up for resolution then.

Joe Andrieu: I agree.
… The rubric should be ready for review by then.

Ivan Herman: I prefer February. January is too close to the holidays.
… End of Jan is better.

Daniel Burnett: There is some agreement on end of Jan-Feb.

Phil Archer: No one works in Dec. Can we meet then?

Daniel Burnett: That has never worked out for me, but I love your enthusiasm!
… Can we tack on to another event?
… Are there conflicts that you are aware of.

Michael Jones: fido is first week of feb 2-8
… RSA is FEb 23-28 SFO
… FIDO in Hong Kong.

Daniel Burnett: Hosting?

Ivan Herman: If it is in Feb-March, I could explore hosting in Amsterdam.

Michael Jones: Last week in Jan is clear.
… MS can get rooms in Redmond, SFO, or London.

Ivan Herman: Europe would be fair.

Joe Andrieu: RWOT location is March Buenos Aires.
… Not finalized yet.

Daniel Burnett: Your preference has been noted, Ivan ;)

Pamela Dingle: Microsoft joining the DID WG has been approved. Daniel Buchner, Mike Jones and myself will be representatives.

Markus Sabadello: [Overall welcome]

3. Rubric for Decentralization

Ivan Herman: See starting slide for Joe’s presentation

Brent Zundel: we have a presentation by JoeAndrieu now
… …to talk about Rubric for Decentralization

Joe Andrieu: meta-level introduction: this work has happened so far outside of WG so far (and outside W3C)
… we hope it will flow into this WG
… Rubric for Decentralized characteristics is in WG charter
… what’s a rubric? why a rubric for decentralization?
… A rubric is a scoring guide, used to evaluate performance or a product or a project
… it’s also a religious term (but that’s not what we’re talking about)
… (showing an example of a Rubric of “Digital Storytelling Assignment”)
… there are categories, ratings, and descriptions what ratings mean
… e.g. ratings include Excellent, Good, Fair, Poor for a sample category
… (showing more examples on slides)
… there are different structures to the possible sets of answers
… other types of responses can be useful
… Why a Rubric for Decentralization?
… this work started after a proposal for a “did:facebook” method
… we realized there’s no good definition of “decentralized”
… could “did:facebook” ever be decentralized?
… what if Facebook made a DID method that is actually decentralized?
… should there be requirements for DID methods to be “decentralized” in some sense?
… it was frustrating not to have a shared understanding of “decentralized”
… how can we have a definition we can share
… we all had a slightly different understanding.
… so how can we evaluate DID methods. what is it about people in community that got us interested in DIDs?
… it’s a tool for evaluating specifically DID methods
… our goal is to be objective and non-judgmental. we want to minimize bias, avoid advocacy
… people who make DID methods should be able to differentiate
… this is relative to an evaluator. different evaluators will arrive at different results.
… example: cost of DID method governance
… e.g. it costs money to travel to conferences. this is only accessible to some for economic reasons.
… so in order to evaluate a criterion such as cost, it depends on who evaluates it
… there is no “summary rating”. there is no “i’m 95% compiant with the rubrics”. it’s more about trade-offs and comparion
… what we are working on is a single “Rubric”. it consists of multiple criteria with multiple possible answers.
… a criterion is important or not depending on the use
… it can be filled out by a specific evaluator for a specific method. and you can add comments/notes while you evaluate it.
… (showing an example of a Rubrics that’s neutral)
… amusement park ride example: question is “how tall is the rider”. answers are “<3”, “between 3 and 4”, “>4”. there is no good or bad, it depends on the situation how a certain answer applies to a certain situation
… this topic started during a passionate debate in CCG
… several sessions at IIW28
… for RWoT9 I wrote a “creative brief”
… several members of this community have been collaborating at those events
… we’d like to feed this work into the DID WG
… (showing Google Doc of initial write-up)
… example criteria: is it permissioned? how open is the governance of the network?
… example answers: 1. anyone can participate in consensus fully, 2. all participation is permissioned. etc.
… example criterion: fiduciary commitments. does a fiduciary put your interest above their own?
… existence of a fiduciary role in a system is a form of decentralization.
… (showing DID creative brief in Github)
… in my experience, doing a “creative brief” is useful before starting to collaborate on the actual document
… .. in order to get collaborators on the same page. what are you trying to do, who are you trying to reach, what are tactical objectives, etc.
… we want this to be simple to apply
… we want to help standards collaborators to make better decisions on what DIDs can be used for.
… we want to help DID method creators evaluate trade-offs in their DID methods. this can help design better DID methods specifications.
… this may also help decision makers choose between available DID methods
… non-goals: no top-level metric (“97% decentralized”). no framework for certification.
… we want a subjective, qualitative evaluation. some criteria are soft and fuzzy and don’t fit into a hard metric.
… this will not be exhaustive. just capture what drives the work in the community.
… it will not directly provide guidance beyond DID methods.
… it will not provide guidance whether or where DID methods should be published (in a registry)
… however, some registry maintainers may decide to use the rubric
… source of credibility for this work: involved people are experienced in the DID work. they include editors, chairs, board members etc. of relevant groups and organizations.
… we want people to collaborate and communicate better. let’s avoid non-productive rabbit holes.
… we encourage people to talk about this, write blog posts about their favorite criteria, etc.
… we had weekly calls before RWoT9, then met at RWoT9
… (showing draft paper from RWoT9 on github)
… our criteria include: network governance, method governance.
… we found it was hard to fit DID methods into our initial understanding of a spectrum of governance.
… we realized governance was a more complex topic.
… example questions: is it governed by a single entity? by a closed set of multiple parties? by an open set of multiple parties?
… another example question: how privatized is the economic interest of the governing authority?
… examples answers: 1. governing authority extracts rent, 2. it enhances profits, 3. it is established for the common good for a limited set of parties, 4. it is established for the public good.
… we are learning new and better ways to think about these questions
… we talked to Arthur Brock of Holochain. looking at “did:holo” helped us get new perspectives on the criteria.
… possible next step: propose initial draft for DID WG.
… solicit criteria, collect, collate, filter. determine relevance.
… or comments ?

Daniel Burnett: “criteria” is plural. “criterion” is singular.

Pamela Dingle: I expect the roadmap must include a glossary. e.g. define “privatization”
… doesn’t have to be perfect now, but all words need to be strictly defined at some point

Joe Andrieu: yes we already found that in our conversations. words matter.

Pamela Dingle: can we look at section 6.0.4
… are we talking about fiduciary commitments of a wallet? what does that mean?

Joe Andrieu: e.g. coinbase may or may not have a fiduciary commitment to its users

Pamela Dingle: how is this relevant for DID methods?

Joe Andrieu: i think this only makes sense if a DID method specifies a wallet. so this may indeed not be relevant.

Manu Sporny: is this a complete set of categories, are we adding more?

Joe Andrieu: yes we’re going to add more

Manu Sporny: good that this is happening. this was a point of contention.
… at some point we need to be “done”. when is that going to be? because this could keep going for a very long time.
… the larger the rubric gets, the less useful it becomes
… once you have this and people can self-report, would it be useful to compile it for e.g. 10 existing DID methods
… this could then trigger more criteria to be added, after doing some initial evaluations
… 1. how long does this go on?, 2. are we compiling a list of evaluations?

Joe Andrieu: reg. 1.: not sure about the exact timeline, but at some point we will decide to publish it
… drummond filled out the initial evaluation for did:sov. this triggered more discussion
… others have tried to apply it (e.g. uport, jolocom). so we already have some experience with how it works
… evaluations are subjective

Drummond Reed: this is fantastic

Joe Andrieu: google doc: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?usp=sharing

Drummond Reed: reg. pamela ‘s comments: a wallet can be involved in a DID method. so properties of a DID methods can depend on properties of the wallets that are used (e.g. for key generation)
… reg. manu ‘s comments: we need to engage method authors to evalute their own methods, rather than a core group evaluating every method.
… there is tremendous marketing value in this. it will help to educate a larger audience on what DIDs are about.
… other work will happen that will reference this
… others (e.g. DID method authors) will use this to describe/promote their work
… neutral parties could evaluate DID methods (e.g. similar to EFF’s secure messaging scorecard)

Daniel Burnett: do you intend the rubric to be able to distinguish between methods? is this the goal

Joe Andrieu: not necessarily. multiple methods may have very similar evaluations but differentiate in other ways

Kenneth Ebert: is there any outreach to DID methods that are not participating in this meeting?

Joe Andrieu: for RWoT paper we won’t solicit extended input. but once it’s in the WG we will reach out further

Kenneth Ebert: what will you do with the responses other than publish them? will you check that they are done correctly?

Joe Andrieu: no, i’m interested in feedback on whether the rubric is useful for characterizing DID methods
… right now, the input we’re interested in is not so much concrete evaluations, but rather defining the rubric / the criteria themselves. the WG should focus on the latter.

Kenneth Ebert: are we going to publish evaluations? or will others do that?

Joe Andrieu: I think we will only publish the rubric
… since we don’t intend to solicit evaluations, there is no intend at the moment to publish them
… however, we are using examples, so we may publish a subset of evaluatios we’re doing ourselves. but we won’t have a well-defined process for that in the beginning

Brent Zundel: so this would be for illustrative purposes on how to use the rubric

Pamela Dingle: some adjectives may be too relative, e.g. “inexpensive”. This could be problematic. Another example is “transparent”, this is also very subjective
… we may need remediation if people disagree

Joe Andrieu: this is up to the evaluator. every evaluator will have to decide for themselves what “inexpensive” means

Brent Zundel: the rubric is a set of criteria. it can be used by a method author, but it can also be used by a user of a method, or anyone else. it’s a tool.

Joe Andrieu: evaluation = what happens when an evaluator applies the rubric to a DID method

Drummond Reed: suggestion: i think there could be a way to accelerate this work. the group could invite DID method authors to come up with their own explanations of why they think their method is different, and why their method is needed in addition to all the existing ones.
… we can see what they believe is different about their methods

Joe Andrieu: (showing working document in Google Docs)

Brent Zundel: thanks everybody. Moving on to next topic.

4. Concerns and Requirements for adopting work items

Manu Sporny: (showing slides on how to adopt existing work)
… we had some disagreement yesterday, some miscommunication
… what are the concerns when this group decides to adopt work from the CCG or from other groups
… those concerns will drive requirements
… e.g. if concerned about IPR, we must do X….
… different people may have to be involved on different levels
… what are the concrete requirements (example discussions: open Github issues must be preserved? what about open PRs? etc.)
… there were concerns around intellectual property commitments. this is an important concern.
… another concern was that the WG has to have the ability to revisit previous decisions
… WG is more formal than CG, therefore we may have to go back and question certain decisions
… another concern was continuity (e.g. should the fine-grained Git commit/issue/PR history be preserved and visible)
… also concerns about messaging to the broader community (e.g. a feeling that work may be “taken away” from someone)
… also concern about amount of efforts that are necessary (e.g. for work required to set up and move Github repos)

Ivan Herman: the last one is not a matter of effort of the W3C staff. Rather, what matters is the necessity to fit everything we do into the existing W3C infrastructure. This includes concrete tools to be used.

Daniel Burnett: there may be more or less work for W3C staff depending on how we set up things.

Ivan Herman: yes but the main requirement is that all tools are available and set up correctly, the staff’s effort are not relevant in the evaluation.

Gregg Kellogg: we had a similar experience in JSON-LD CG transition. we already discussed some pros/cons of moving the Github issues.
… regarding issues and PRs: what we did was to re-create new PRs in the new repo with references back to the old PRs in the old repository
… some issues pointed back to old issues. they may be closed in one repo but still open in the other.
… if you re-create PRs, it’s hard to move them in an automatic way
… in the DID spec, we have 8-9 open PRs. perhaps we should close them and simply ask the authors to open new ones.

Manu Sporny: moving on to concrete requirements.
… we had consensus that open issues must be preserved. then we can triage and process them.

Brent Zundel: we’re talking about moving from the CCG did-spec repo to the WG repo.

Manu Sporny: this discussion is generic to all the work we’re doing, including DID spec, rubric, use cases, etc.
… 1. preserve open issues, 2. preserve PR, 3. there must be a specific established point in time when the WG took over
… open question: do we want to pull in close issues and closed PRs (if it’s easy)
… open question: do we want to preserve commit history (if it’s easy). is anyone concerned about that?

Joe Andrieu: i like what the commit history shows us in terms of contributions
… one issue with requirements: what do we do with PRs from non-WG-members?

Manu Sporny: we can close them
… we can trace exactly who contributed what lines to the spec
… from my perspective, preserving the history has no downside and multiple upsides

Daniel Burnett: let’s stop using the term “preserve”. we never considered “deleting/erasing” any history.
… we talked about archiving
… using the term “preserve” sounds like moving the history into the WG. it sounds like if we don’t do it, everything is gone
… but even if we don’t move the history to the WG, it’s still “preserved”, it’s not gone

Kenneth Ebert: let’s distinguish between open and closed PRs.
… let’s be clear on what exactly we’re moving/preserving/closing/etc.

Manu Sporny: so what should we do with commit history

Ivan Herman: commit history will be there in any case. the question is where it will be.

Daniel Burnett: precise discussion is around “complete commit history must be in WG”, rather than “commit history must be preserved”.

Manu Sporny: do we agree on having the complete commit history in the WG?

Ivan Herman: do we need to have it in this particular repo?
… i don’t see the particular need to have it in that repo. i haven’t heard a good reason

Michael Jones: this may be unpopular: this seems like an administrative decision left to chairs and W3C staff. it doesn’t matter directly for the work of the WG itself

Drummond Reed: +1 to Mike’s point

Michael Jones: my meta-point: this is not a good use of our time

Gregg Kellogg: one argument i can see for having the history in the repo is that for editors, git tools can be used to check where/when certain contributions happened. it affects editors, so it should be up to them.

Manu Sporny: +1 to that. the editors and chairs and staff can figure it out.
… as an editor, it is very important to understand who put something into the spec.
… e.g. your view may be that a certain change is editorial, but the original author may disagree. having to jump between multiple repos increases the burder for editors.

Daniel Burnett: it is not a waste of time to make sure that everybody’s point has been heard
… articulating all points is a valuable use of time. after that, a decision will be made.

Michael Jones: i haven’t heard us talk about editors. there are no editors yet, so they can’t be heard.

Daniel Burnett: do you want to first select editors or describe the process how editors will be chosen?

Michael Jones: what i said was that “editors + chairs + staff work it out” is not possible since there are no editors yet

Manu Sporny: moving commit history is easy via Git rebase operation

Daniel Burnett: please raise your hand if you have an opinion on availability of complete Git history in the WG

Amy Guy: I think it should be available

Markus Sabadello: (5 people raised hands)

Daniel Burnett: now raise hands if you think the full commit history must be available in the WG repo

Markus Sabadello: (4 or 5 people raised hands)

Daniel Burnett: we will select editors at some point

Manu Sporny: last issue: must closed issues/PRs be available in the WG repo? does anyone care?

Amy Guy: I think closed issues should be available because thoughtful people search existing issues before raising a new one. We might get repeats if they don’t think to search the old repo

Manu Sporny: if we preserve the full commit history, many commits reference issues or PRs. so if we don’t move all of those as well, then the pointers will be wrong. i.e. commits will point to wrong issues/PRs

Pamela Dingle: I thought the input to the WG is a document. are you telling me now i have to read years of history as input to the WG?

Ivan Herman: +1 to pamela

Pamela Dingle: i understand the interest of the community to preserve the history. but the document is the input.

Gregg Kellogg: yes there is value in history. agree with pamela that the group agreed to start with a snapshot of the document.
… if an editor changes something in the WG that upsets someone in the CG, then that CG member should join the WG and contribute there

Daniel Burnett: it’s not a problem to raise old issues again
… pamela’s point is a good one that the input to the group is a document, not the rest

Manu Sporny: i’m trying to get to something concrete we can do. the simplest thing is to just transfer the repo.
… since we decided against that, we are having a long discussion on what/how to move manually
… nobody is asking anyone to read the whole history, but the editors need that to do their job
… if we don’t move history, it will result in more work for the group
… the group needs to make a decision that’s actionable, we have semi-conflicting requirements

Daniel Burnett: about the repo as a whole. we had reasons why we didn’t want to transfer it as a whole;
… i thought you (manu) told me that there is no problem with transfering

Manu Sporny: no, that was a different conversation

Ivan Herman: i did talk to Ralph during the break, he was not saying “no”
… the point is there were yesterday several people who were against moving the repo, because we wanted a clear cut. and there were technical issues about transfering the repo

Drummond Reed: I am beginning to wonder about Pam’s suggestion of just taking the CCG Community Final Draft as input to the WG into a clean repo and asking for all issues and PRs to be new ones.

Joe Andrieu: i don’t think we have consensus on the requirements. a lot of us want to move on and leave the decision to the leadership.

Brent Zundel: the point of this session was to hear all points and come to consensus. there is no consensus, so the chairs will make a decision.

Markus Sabadello: (end of session, group is going to lunch now)

5. DID resolutions

Ivan Herman: See start of presentation slides

Markus Sabadello: DID resolution is getting more interest, because once you have DIDs, you need to use them.
… There are use cases just for identification, but others are meaningless without resolution.
… It’s the process of getting from a DID to a DID document. Similar to domain-name resolution
… It’s not a protocol, which is what people usually expect, such as for HTTP. But, it doesn’t work the same way.
… It’s more like an abstract function or algorithm. The process of how this works is method-specific.
… Some methods may not require any network resolution, such as peer and key DIDs; resolution involves constructing an ad-hoc document.

Phil Archer: Can you give examples of read DIDs

Markus Sabadello: Sovrign, and others define access that requires a block chain. A resolver would need to interact with that ledger to do the resolution.
… IPFS, or peer-based require very different steps. Peer DIDs require each peer to keep their own log of DIDs, there is not central truth.
… THis means the DID document is not necessarily an actual document or text stored anywhere. It may be a virtual structure that is constructed dynamically.
… Some methods natively store documents, others just store the bits and pieces that make it easy to construct the document.
… DID resolution is defined to be a process that executes the operations (e.g., read)
… The CCG has been meeting for a year or so which has resulted in different releases. Not necessarily ready for implementation, but is a good start.
… It’s out of scope for the WG to work on resolution (right now).
… (examples of how resolution works)
… Verifying a signature may require DID resolution to discover one of the public keys to use that to verify the proof of the document.
… Several communities are working on DID-Auth, involving a challenge-response, which is also out of scope for this WG.
… Resolution required to discover PK as well as other attributes of the DID.
… DID documents can contain service endpoints for things like security or agents or other ways to interact with a subject.
… The DID spec describes the syntax of a DID and DID URLs, including an information space under the DID.
… Similar constructs to HTTP paths, including matrix parameters, which is a proposal by TimBL for associating key-value pairs with a URL which are different than a query string.
… If a path is a way of organizing an information space, the matrix parameters are a way of influencing what a DID URL dereferences.
… We use the URI spec, so we must be careful to align DIDs with that spec.
… Resolution means determining an access mechanism through which you can interact with a resource.
… Dereference means to execute an action on that resource.
… First resolve to know how to interact.
… The DID resolution part is method specific. THe dereferencing is to execute an action on a resource, which typically means to retrieve the resource, which we may want to specify in a method-independent way.
… Mostly, path, query, and fragment are unspecified, so that method developers are free to make use of these URL parts.
… THe trivial case is a DID itself, which means to retrieve the DID document.
… Another use case includes a fragment identifier, which would refer to a part of the DID document.
… The meaning of the fragment is not based on the URI scheme, but based on the MIME type.
… These are mostly the same as used in HTML and SemWeb (see Cool URLs)
… It seems useful to have a URL (vs URI) to get a specific resource from a document.
… Matrix parameters might describe specific versions of documents.
… (list of matrix parameters)
… Not a protocol, but an abstract functions which can be realized using different technologies.
… They way its resolved can influence the results.
… DIDs may refer to other DIDs or use HTTP-like redirects.
… Right now, DID resolution is out of scope, and could continue in CCG. The ABNF is in-scope, but how you process them is out-of-scope.

Ivan Herman: A flag to ourselves that the DID scheme is currently registered provisionally, and this will need to be made official at CR by someone at W3C. It should be part of the final document as well.

Joe Andrieu: Perhaps we should be “dereferencing” in the spec title, and it’s confusing for people if its not there.

Drummond Reed: +1 to the DID spec including the registration of the mime type

Phil Archer: I might be behind an ISO group on dereferencing, and we may have something closely related. Can’t explain right now, but I would have liked to spend time on it.

Dan Brickley: regarding DID deferencing, if there is an expectation of using fragment IDs pointing into JSON(-LD) documents, then whatever deref protocol is used will need to provide the appropriate media type information.

Daniel Burnett: danbri, good point, thanks

6. WoT joint session.

Hadley Beeman: TAG introduction. We’re interested in seieng how you’ve come along and how we can help.

Michael McCool: WoT is a WG/CG for around 2 years. THere’s some overlap and potential collaboration.
… We’re targeting IOT devices applying web architecture to define requirements and supplement IoT for the web.

Dan Brickley: (there’s also an Interest Group since 2019; proposed charter update https://www.w3.org/2019/07/wot-ig-2019.html )

Dan Brickley: (er since 2015, sorry)

Michael McCool: We have two deliverables, the Thing Description (dataschema for payloads) and an abstraction of how to work with a device.
… There is a binding to a particular protocol, describes in Binding Templates.
… The main deliverable is a TD, which as a JSON-LD document.
… The relevant bit is that we need to identify both devices and users.
… We’re looking at service directories with access control, and need to identify both users and devices, although this becomes an indirect tracking risk.
… (could use a device to track a person).
… IDs could be mutable, but this might complicate other use cases.
… It seems there’s a lot of overlap with DIDs.
… There are other related things; a TD describes a single device, there’s also a template that describes generic properties of instances of devices.
… The device might be private, but the template does not need to be.
… In our new WG charter we have a long list of things to accomplish, but three of them directly relate to DID.
… Identity management needs to be done in a way to keep track of devices and owners and assign roles.
… You might be in a smart home use case where access is uniform, but a smart city might have stronger access control requirements.
… We’d like to have a consistent way of doing things that addresses the different use cases.
… In Discovery, we were told by the privacy group that we didn’t have enough pieces together.
… We don’t have a defined way to get a TD and what its lifecycle is.
… By discovery, it might a search engine with a set of IPs. both global and local context problems.
… We’d like to work off of existing work, there may be 2 phases, first contact (opaque and anonymous).
… Later, authenticate and look for devices.
… IETF doesn’t take into account privacy sufficiently.
… We’d like to work on IETF resource directories.
… The TD describes what you’ve discovered. When it’s time to change an ID I’d like to notify users that it’s changed (based on authorization).
… We’re still in the stage of defining requirements and scope of existing standards.

Manu Sporny: Looking at these requirements, DIDs are a part of it, but VC might be related too.
… There are things like object capabilities, authorization capabilities that might fit in.
… Identify management seems like VC+DIDs.
… A DID registry might find all DIDs, but not specific.

Michael McCool: might be two directories.

Manu Sporny: The interop profiles are confusing.

Michael McCool: these are things that are new and challenging. Not everything is relevant to DIDs.

Manu Sporny: constantly shifting identifier is challenging.

Michael McCool: real requirement is privacy. Mutable identifiers is a requirement, otherwise a tracking risk.

Manu Sporny: Delegation of authority use cases.

Drummond Reed: +1 to delegation of authority being another DID + verifiable credentials capability

Manu Sporny: People working on object capabilities.

Michael McCool: I didn’t highlight security issues, but we have somethings OAuth related we’re working on.
… We need to sort how out to handle HTTPS in a local context, and don’t want to define schemes.
… There are things like ACE and tokens that provide similar capabilities.

David Ezell: I’d reather see “identifier management” than “identity mangaement”

Dan Brickley: +1 re identifier management

Joe Andrieu: +1 for identifier management

Drummond Reed: One of the DID methods is sovrin, which is a public ledger for DIDs with a foundation behind it with 5 different task forces, including SSI and IoT.
… Those groups would love to talke with you about it.
… The code-base is at Hyper Ledger.

Michael McCool: we’re interested in that stuff.

Phil Archer: THe Barcode people would say you don’t need any of that, you already have it.

Tobias Looker: Cryptography and self-authenticating identifiers could be useful in a TD.

Michael McCool: we also have security risks on if people fiddle with a TD to point elsewhere.

Drummond Reed: Can Michael share contact info so we can reach him after this session?

Kenneth Ebert: Some people thing about DIDs as unique identifiers, but you could have multiple DIDs associated with a Thing that are used in different ways.

Michael McCool: could be pair-wise identifiers.

Daniel Burnett: (contact info to be sent out)

7. work through issues

Ivan Herman: Do we have a quorum for making decisions with 7 pro-forma members?

Brent Zundel: people can always object.

7.1. Use Case issues

Brent Zundel: If we want to proceed with an existing issue, we’ll create a new one and point back to the original.
… issue #2.

Manu Sporny: what’s the action?

Joe Andrieu: I read the issue and link and think we’ve addressed it.

Daniel Burnett: If the CCG thinks ie can be closed, we don’t need to deal with it.

Brent Zundel: issue #3 – long term credentials and timestamps.

Joe Andrieu: On Ledger there are timestamp attributes you can take advantage of, but we don’t have a use ase.
… We’ll adopt it in the WG, but we’ll leave it open until it’s done.

Ivan Herman: See WG’s Use cases’ repository

Brent Zundel: We’ll bring it over.
… issue #5 – 10 design goals

Joe Andrieu: Think it’s resolved.

Brent Zundel: issue #6 – differentiate DIDs and DID Documents

Joe Andrieu: There is a version of what he’s asked for that was part of the draft, but I ddin’t have time to get concensus. I like the suggestion.

Ivan Herman: Not a use case issue, but a separate document.

Joe Andrieu: Sometimes the use case document as about identifying gaps.

Manu Sporny: It seems vague; I wouldn’t know what to do.

Brent Zundel: I think there’s some value here, and if he things we can do something, we should bring it over.

Joe Andrieu: This chart (in my head) is going to be a catalyst for controversy. Both good and bad.

Brent Zundel: Use cases or another note.
… We could move the issue over (to WG)

Action #1: move issue to WG for potential new note. (Daniel Burnett)

Brent Zundel: issue #10 – portability/substitutabiliy

Joe Andrieu: There have been schemes discussed about how you might take a DID from one method and forward to a DID on another method. We should add it.

Brent Zundel: We’ll move it over.

7.2. spec issues

Brent Zundel: issue #82 – Fragment identify semantics
… We may determine that the CCG triage is not what we’d do.

Manu Sporny: We should pull this in. Not editorial.
… We’re trying to say that frag identifiers are associated with the mime type.

Ivan Herman: It may be that the fragment identifier is defined for the JSON-LD type.

Manu Sporny: gkellogg: I believe that JSON-LD does describe how MIME types are related … fragments, look in IANA section. We do heavily make use of fragment identifiers.

Manu Sporny: gkellogg: I’d say it’s done, if not, it should be an action to refer to JSON-LD group.

Markus Sabadello: It sounds like the DID doc is defining fragment semantics for a DID scheme, but it shouldn’t do that.

Ivan Herman: issue should be brought over.

Markus Sabadello: See https://w3c-ccg.github.io/did-spec/#fragment

Daniel Burnett: danbri had a comment about frag identifiers. If we’re going to allow for them, the documents returned need to have a media type.

Brent Zundel: issue #112 – intro is incorrect
… Done, close

Amy Guy: brent, hang on, not necessarily addressed maybe just mentioned as ‘towards’

Amy Guy: I think most that got 100% addressed were closed

Amy Guy: okay never mind this one was addressed

Brent Zundel: at 4:30 people from PING coming to discuss our relationship.

Ivan Herman: There has been a lot of discussion on horizontal review that groups get there too late.
… When we have FPWD, we should let them know it’s there for them to look at.
… Also, PING, I18N and Accessibility have forms for us to consider.
… There’s a lot to look at, but much is irrellevant. We should not wait for CR, but do way before.

Michael Jones: It is time

8. controller terminology usage

Brent Zundel: Making the homepage more visitor-friendly is one possible topic
… We could discuss DID Controller - proposed by Joe

Joe Andrieu: DID Controller is related to DID Authentication
… There was a question on the CCG mailing list about the Controller property and the Authentiation property
… He didn’t make it through understanding the relationships
… asked Marcus about it

Markus Sabadello: there are multiple ways of seeing it and different views
… There are many DID methods that don’t use the DID document
… There isn’t a method-independent interpretation

Joe Andrieu: There was a discussion between Sethi Shivam and Daniel Hardman
… The spec text is not aligned with what most people think it should mean

Daniel Burnett: If it’s not in the authentication section of the document, where is it?

Manu Sporny: Some methods will use the Authentication section to allow you to update the document
… Other methods may do something totally different
… This is old text that is wrong and needs to be updated

Joe Andrieu: The keys that can be used to update can be used to impersonate

Manu Sporny: In veres1, DID documents are capabilities
… In veres1, different keys are used to update the document
… Will open an issue

Markus Sabadello: The name of the top-level property is Controller, whose value may be another DID

Manu Sporny: The Controller field tells you what DID controls that document
… This could be used by organizations

Joe Andrieu: For BTCR, the Controller would be ignored

Daniel Burnett: It’s not clear to me what the difference between Control and Authentication is

Joe Andrieu: Whoever controls the document is omnipotent for all content in the DID document
… The Authentication section specifies the mechanism for authenticating as the DID - a legitimate claimant to act as a subject of the did
… … so that entities using that Authentication mechanism can use the DID for DID auth, but can’t necessarily change the DID

Daniel Burnett: We talk about who proves control over the did by authenticating to it, not by being the controller

Joe Andrieu: We have a limited authorization to authenticate on behalf of the DID
… These semantics are confusing

Michael Jones: Is the terminology in the document currently contradictory and confusing?

Brent Zundel: Yes

Joe Andrieu: There’s a distinction between who can change the DID document and who can authenticate as it

Daniel Burnett: Asked in one case whether the party is a controller or an authenticator

Joe Andrieu: Related to subject versus holder
… Sometimes they are the same - sometimes they are not

Brent Zundel: In the subject versus holder debates we had two terms

Joe Andrieu: A possible term is governor

Daniel Burnett: The term DID Subject makes sense to me

Drummond Reed: If the DID Subject is the entity identified by the DID, then we could separate the DID Controller from the DID Document Controller

Ivan Herman: I don’t like the term DID Controller and a separate DID Document Controller, confusing

Michael Jones: What are the next steps to resolve this?

Brent Zundel: Wanted to ask the same thing
… We’ve created several issues. Manu, can you point us to them?

Manu Sporny: They are issues #2 and #3

Manu Sporny: Created two new issues: https://github.com/w3c/did-spec/issues/2

Manu Sporny: … and https://github.com/w3c/did-spec/issues/3

Drummond Reed: If we use DID subject as the entity identified by the DID, the other two roles have to be named
… The entity the proves control of the DID document
… The entity that can authenticate that it has control of the DID
… The entity that controls the document could be one of the parents - the other could be the other parent
… I’m not suggesting terms for the other two

Markus Sabadello: My assumption in the DID spec is that we are mostly defining things that are method independent
… The controller construct doesn’t make sense for BTCR
… … how to log into a Web Site with a DID

Brent Zundel: We’re going to pause that conversation now for the PING discussion

9. Meeting with the PING

Brent Zundel: I’ve been working in the PING for a while
… A difficulty of the work is connecting with the working groups to provide timely, actionable feedback
… We want to know who you are and how to best work with you

Christine Runnenger: It would be useful to have an overview of what you’re trying to accomplish in this group

Daniel Burnett: Tara Whalen, PING co-chair

Brent Zundel: Our primary recommendation is to define Decentralized Identifier
… Identifiers that don’t require association with a centralized party

Drummond Reed: Identity, security, and privacy are the holy trinity of the Web.

Brent Zundel: You can prove control of them independent of third parties
… There’s the DID, the DID Document, and DID Methods

Drummond Reed: I work in one of the companies in the space
… DIDs are foundational technology for privacy by design at Web scale
… Architecture supports the range from public to pairwise
… It’s useful talking about the relationship between DIDs and Verifiable Credentials

Manu Sporny: PING came into Verifiable Credentials late
… The larger ecosystem is Verifiable Credentials
… We want people to be able to go organizations and get credentials from them and share them where they choose
… Correlation is an issue
… Question is how correlatable is the identifier
… There are currently 30 types of DIDs
… These are about the identifier
… Cryptography lets you do authentication and know who you are talking to
… We all care deeply about privacy
… Is there a way to shift where your information is stored, putting the individual in charge?
… With their software helping them make better privacy decisions
… DIDs can be like super tracking cookies
… Over their lifetime, the people they share them with can do correlation behind the person’s back
… There are zero-knowledge proofs being used with Soveriegn
… The feedback that the WG would like from the PING is what privacy issues they see

Daniel Burnett: We had an intention that these identifiers would be reasonably cheap and easy to create
… There are use cases where you’d use different identifiers
… If to sign in, I have to demonstrate that I’m over 18…

Tara Whalen: It’s good to hear that there are many security and privacy engineers working on this
… It’s good to give us information early
… You seem to be miles ahead of some of the other groups
… Where are you in the process?

Daniel Burnett: We are not yet at first public working draft

Brent Zundel: We selected what will become our first editor’s draft yesterday

Christine Runnenger: It’s apparent to me that you’re early in the process
… Thank you for reaching out early
… Look at the updated security and privacy questionairre
… You’re in the best position to decide when you need input from us
… For instance, ask us to look at specific issues in GitHub

Joe Andrieu: There are specifications for DIDs and method specifications
… We’ll be enabling self-tests

Christine Runnenger: Is what Joes was describing like a profile?

Michael Jones: (the question wasn’t answered)

Ivan Herman: Many of our use cases are different than others you may be familiar with; we do not have direct relationships with, e.g., browser API-s

Drummond Reed: The specification we’re chartered to do creates a new kind of URI - a DID
… Explained the syntax of a DID URI
… There’s an informal registry that the Credentials Community Group maintains of DID types

Michael Jones: What are the privacy implications of each DID method defining its own protocol

Drummond Reed: Every DID method will have to have its own privacy analysis
… The spec is already the result of three years of work
… It’s a requirement on DID method specifications that they have a Privacy Considerations section and that they address certain things
… It would be good to have PING review these guidelines

Manu Sporny: A mistake we’ve made in the past interacting with PING is isolating the conversation to the spec we’re working on
… Data models don’t have the same privacy implications as protocols
… We need to discuss the ecosystems wholistically
… We could say “it’s just an identifier” but there’s a larger usage context with privacy implications
… Can we tag our issues with a privacy tag to help you when you use our GitHub issue tracker?
… Or is there a more effective way to work?

Christine Runnenger: Tagging issues would be fantastic
… The W3C staff need to use some machinery to create the tag
… You could appoint Brent as your PING liaison

Ivan Herman: Is this mechanism already operational?
… There are special labels that you can add that will ping PING

Drummond Reed: Sovereign spends a lot of time on privacy
… DIDs and Verifiable Credentials used well are the basis of Privacy by Design at Internet scale
… We’d like to examine separately from our spec the use of DIDs to create an ecosystem
… Used wrong, DIDs can be the greatest tracking cookie ever
… Used right, they can be a solution to surveilance capitalism

Christine Runnenger: I worry that DIDs could be used for evil
… You appear to be catering for the use case of a globally unique persistent identifier
… It might be worthwhile having a chat with the Security working group

Drummond Reed: Security, privacy, and identity are a triangle
… The Security Considerations section is also quite long

Brent Zundel: Thank you very much for coming!

Christine Runnenger: Did the community group produce a Use Cases document?

Drummond Reed: Yes - and it’s a good one

Joe Andrieu: Feel free to reach out to me about it

10. Open topics

Brent Zundel: We can switch back to open topics now

10.1. Back to the terminology question

Joe Andrieu: I think that third role may be acting on behalf of the DID: A term could be DID Actor

Drummond Reed: +1 to DID actor

Joe Andrieu: Or it could be DID User

Daniel Burnett: Drummond used an example of a child and two parents. I care a lot about the guardian use case.
… There are cases where someone else has some of the rights of a person on their behalf
… There are also the courts, which can change those relationships
… We should have an example illustrating these use cases

Drummond Reed: Reminder to talk about several examples of the 3 roles

Brent Zundel: Andre, is your comment related to the DID Controller, etc. conversation?

Andrei Sambra: We speak of delegator and delegate. Actor would be confusing to many people.

Michael Jones: +1 that “Actor” is overused and confusing

Drummond Reed: There’s agreement that three terms are needed
… We should all take the action item to think about this and possibly take it to the list

Joe Andrieu: +1 delegate

Brent Zundel: We have two issues about this - #2 and #3
… Should the issues be updated to talk about the three roles?

Manu Sporny: Yes

Brent Zundel: With these issues, do we have enough recorded that we can move to a different topic?

Daniel Burnett: Let’s get other possible topics out on the table
… One is external communications
… Such as who are the editors

10.2. workmode, editors

Manu Sporny: It would be good if the editor’s were given free reign to clean up the spec
… There are larger issues that might help the editors work faster
… Some things could be ripped out
… What do we think we can rip out before we start adding stuff?

Drummond Reed: +1 to the editors being assigned to do a cleanup pass

Brent Zundel: The three CCG members who have edited the CCG spec are Manu, Drummond, and Marcus
… Do you all want to continue editing and do even more work than before?

Drummond Reed: Yes, I am indeed married to this spec :-)

Brent Zundel: All three will continue as editors

Daniel Burnett: We are looking for people who will do the work
… We may adjust the editors as we see other people contributing
… We have new people and organizations that weren’t involved in the CCG
… Please come talk to us if you want to be considered as an editor
… We’re paying attention to who’s doing the work]

Ivan Herman: All the repositories have separate teams that have write and administrator access
… Editors could directly commit

Michael Jones: We should always use PRs to enable working group review

Manu Sporny: We should add Amy as an editor. She’ll be doing the work anyway and should get credit for it.

Drummond Reed: Amy did outstanding editorial work

Brent Zundel: The chairs will have a conversation about that

Daniel Burnett: If the editorial team gets large, there’s an interesting question about editorial decisions are made
… Four is a really large group for active editors of a spec

Markus Sabadello: I would have also proposed Amy
… In the CCG, we always created PRs and had editors approve it

Joe Andrieu: I also want to endorse Amy
… If four are too many, you should consider which of you are willing to give up your spot for Amy

Gregg Kellogg: It’s typical to also list Authors as well as Editors

Drummond Reed: And that means Amy is the Red Queen, right? ;-)

Daniel Burnett: Are all the editors expecting to do editing work or just contributing content?

Ivan Herman: What about editors for the Use Cases document?

Brent Zundel: Joe, will you continue?

Joe Andrieu: Yes
… And I’d like a partner in crime

Drummond Reed: +1

Ivan Herman: Phil Archer may want to be a Use Case co-editor

Brent Zundel: Editors for the Rubric

Joe Andrieu: Point of order: We do not yet have a Rubric work item. We should defer until we do.

Manu Sporny: A lot of the CCG work lately has been working on the charter
… Over the past two years things have changed in implementations that have not been tracked by the specification
… An editorial pass seems necessary
… For instance, the conversations about did:web put off editorial work
… It’s mostly to remove things that no longer apply

Michael Jones: Changing spec features and normative behaviors is not editorial

Drummond Reed: We deprioritized some of the change requests that were coming in

Brent Zundel: I would want to know very explicitly what the scope of the work is that the editors propose
… Our first act with the document shouldn’t be to cut massive sections out

Daniel Burnett: Minor cleanup that’s actually editorial is fine
… It doesn’t matter that people in the CCG said that changes should happen. They didn’t appear in the document that they produced.
… One of the biggest risks for groups is editors making changes that people don’t feel were agreed to

Amy Guy: There are still a lot of editorial issues, mostly around the overview and introductory sections (https://github.com/w3c-ccg/did-spec/issues?q=is%3Aissue+is%3Aopen+label%3Aeditorial) but we just didn’t have time to get to them (largely because of other backed up PRs making it difficult I think)

Amy Guy: (in answer to the question why weren’t these done already)

Daniel Burnett: Not all the people who are editors are experienced W3C Recommendation Track spec editors

Drummond Reed: +1 to Amy’s point

Amy Guy: There are a number of editorial cleanups that we didn’t have time to get to

Brent Zundel: One of the first “editorial” issues we looked at today wasn’t actually editorial

Daniel Burnett: We need to be careful

Drummond Reed: +1 to Mike’s point

Brent Zundel: +1 to mike’s point

Michael Jones: WebAuthn and FIDO2 require that issues be created before PRs are created. I request that we adopt that working mode.

Manu Sporny: PRs can describe themselves without having an accompanying issue

Daniel Burnett: Going into Manu editorial mode may not be the right way to start off the working group

Markus Sabadello: There are several events in the near future that we could use for editing and triaging - such as IIW

Drummond Reed: +1 to what Marcus said
… I agree with what Mike said
… We should develop a working-group wide ethic of raising issues, discussing them asynchronously, with an eye towards coming to closure
… Terminology is not purely editorial
… We should discuss terminology early to avoid having it slow us down later
… We should start talking about a roadmap and plan of attack for the next few months. We’re not starting from scratch.
… We should try to understand early what the real issues are

Daniel Burnett: We haven’t talked about what the process is for deciding when something’s ready to go in
… One of the strengths of W3C is that we don’t have a formal process for making changes
… There’s a principle that there’s always a double-check
… The editors have a special responsibility to make sure that they only agree to truly editorial changes without working group review
… Call time is valuable. Some can be used for triaging and assigning issues. Some can be used for discussions. The work also needs to happen outside the calls if we’re going to finish in two years.
… We can also schedule ad hoc calls, if necessary
… We want the minimum amount of process that will result in good results
… We had a spec document that had to get out in the DCWG. I discovered that Amy was editing the spec, at Manu’s direction, without being an editor. That’s not OK.
… There are things we need to be aware of
… We want to make sure that things like that don’t happen

Michael Jones: I assume that IIW what we’d do is create issues and PRs - not do editing

Daniel Burnett: Ad hoc F2F meetings are generally frowned upon
… But people in the same space are clearly free to talk about things
… W3C requires 8 weeks notice before a F2F meeting
… Talking as individuals is always fine - it’s just not a working group meeting
… Individuals can always create issues and PRs

Drummond Reed: I think that’s what Marcus meant

10.3. outreach

Ivan Herman: It would good if this group had a regular outreach to the outside world
… Twitter, Facebook, blogs, etc.
… W3C’s blog is open to WG chairs

Daniel Burnett: I would love to delegate blog summaries to someone else :)

Ivan Herman: At least once a month it would be good to have communication

Markus Sabadello: There are several of us who go to many events and can publicize our work

Drummond Reed: We have two sessions tomorrow
… Helen is here to do the non-technical version of DIDs
… SSI Meetup is asking for a report
… Is doing a Webinar on Friday
… They want to do a “DID Report” on a regular basis

Michael Jones: Helen is at 11:00

Drummond Reed: The second is DID Q&A at 4:30
… It’s a Q&A with us as WG members

Joe Andrieu: I’m on the hook for an article for IDPro
… I’d love to have some help

Kenneth Ebert: In the AC meeting we had a report from the Web of Things on their interactions with us

Pamela Dingle: How long will it take for the editorial triage to happen?
… Do I wait to review the spec until after that or do it it now?

Drummond Reed: Go for it - read it now

Brent Zundel: Thank you for two days of hard work!

Manu Sporny: Thank you to the chairs

Manu Sporny: And thank you Ivan!

11. Resolutions

12. Action Items