DID Working Group F2F in Fukuoka — Second day -- 17 Sep 2019

<ivan> scribejs, set gkellogg Gregg Kellogg

<ivan> guests+ gkellogg

<ivan> scribejs, set pamela Pamela Dingle

<ivan> guests+ pamela

<ivan> scribejs, set helen Helen Garneau

<ivan> guests+ helen

<ken> scribe: ken

brent: 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> slides url: https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit?pli=1#slide=id.g2a8b040676_0_27

<ivan> Yesterday's draft minutes

ivan: Yesterday's minutes are ready as a draft. Please review the names and WG membership status.
... If you are missing please report errors to Ivan.

Test suite

brent: What are your thoughts about the test suite?

<ivan> guests+ selfissued

manu: There is an existing test suite.

<ivan> scribejs, set selfissued Mike Jones

<manu> https://github.com/w3c-ccg/did-test-suite

<ivan> scribejs, set jay Jay Kishigami

burn: Manu will look up what is ready already.
... We need to decide when to do the work on it.

<ivan> guests+ jay

burn: It can be counter productive when we are still arguing about features.

<manu> example of test suite output: https://w3c.github.io/vc-test-suite/implementations/

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

gkellogg: 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: 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:

<Zakim> manu, you wanted to provide what we have right now in the W3C CCG.

manu: 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> https://w3c.github.io/vc-test-suite/implementations/

manu: This is what an implementation report can look like.
... In the basic document section, "context must be..." and shows the number of implemntations that pass a particular test.
... Checks and x's show status.

<manu> https://github.com/w3c-ccg/did-test-suite/tree/add-tests

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

<manu> https://github.com/w3c-ccg/did-test-suite/tree/add-tests/test/latest

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

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

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

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

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

gkellogg: 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: I like Mike's suggestion regarding resolution in the test suite.
... It is very useful to non-normatively cover this in the test suite.

<Zakim> manu, you wanted to mention "one common DID method for testing"... and to respond to Gregg

<manu> Example of "How to run the test suite": https://w3c.github.io/vc-test-suite/

manu: Greg, instructions are here in the VC test suite.
... In the 8-10 implementatinos 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 extentions.
... 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.

<gkellogg> perhaps a “test” method, defined with specific behavior for running tests.

<burn> +1 manu to optional resolution tests, but we must not block group completion on disagreements around those tests

manu: These would be optional tests.

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

<Zakim> brent, you wanted to outline decisions the group should consider

ivan: In other groups we had two or three implemenations that accompanied the spec development.
... This provided valuable feedback along the way.
... It required acknowledgement of "changes will be required"

peacekeeper: With DID URLs, there is some functionality regarding selection of material from the DID document.

<Zakim> JoeAndrieu, you wanted to discuss test suites for DID Methods

peacekeeper: This could be tested in a method-independent way.

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

<Zakim> drummond, you wanted to ask about basic scope of tests and talk about Peer DID and DID Key

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

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

<Zakim> manu, you wanted to say we have an implementation and to note our charter said that we wouldn't do DID Methods, whatever that means... and to note that Andrew is committed to

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

<manu> Out of scope: "Specific DID Method specifications or Protocol specifications"

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

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

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

<Zakim> burn, you wanted to remind people that we cannot block group if disagreements on out-of-scope tests and to point out that we can decide what it means to test a DATA MODEL spec, and

burn: 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: Re: manu's commitment regarding resources, Evernym is working on committing resources.

ivan: Audio problems are going to be fixed in the break.

<Zakim> manu, you wanted to note Markus' did resolver and did-io and the way the test suite works

manu: 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> Can we propose to start with the current CCG test suite?

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

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

tplooker: 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?

<brent> DRAFT PROSOSAL: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.

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

<brent> PROSOSED: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.

peacekeeper: They may be valid but not pass the test suite.

<manu> +1

<burn> +1

<yancy> +1

<JoeAndrieu> +1

<drummond> +1

<Dudley> +1

<grantnoble> +1

<ivan> +1

<peacekeeper> +1

ken: +1

<brent> +1

<rhiaro> +1

<tplooker_> +1

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

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

brent: We have other questions on the slide to review.

burn: 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> +1 to this being something the WG should be open to considering.

manu: Regarding Dan's comment, yes the contention is reducing.

<Zakim> manu, you wanted to be opinionated about the questions raised...

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

<Zakim> JoeAndrieu, you wanted to clarify suggestion about DID methods

<gkellogg> +1 to manu’s points

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

JoeAndrieu: 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: I agree with manu's thinking.

drummond: ... Does it make sense to recommend a method framework for the test suite?

gkellogg: 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> To put it different, I asked if the WG should recommend a test framework that DID method authors should use.

<Zakim> manu, you wanted to note that we could use the existing test suite framework for doing that

gkellogg: An interop fest might be key to demonstrate interop.

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

tplooker: Are non-normative tests using a specific method?

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

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

brent: We can't create a DID method by the charter.
... We could use one or more to test.

<Zakim> brent, you wanted to revisit the charter

selfissued: 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: Is there any controversy regarding how to pull in the test suite?

manu: 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: Does any one disagree with manu?

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

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

gkellogg: The history would remain in the old repo.

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

ivan: We archive the old repos.

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

ivan: Change the readme that says, "Go to the new repo"

burn: I don't want to derail success, but in this case we could just move the repo. There is not a history concern here.

<Zakim> manu, you wanted to say that people don't read

burn: Chairs and editors can work this out.

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

<brent> zzakim, close the queue

gkellogg: In json-ld we had this same problem. We changed the endpoint to autoredirect after a short pause.

<brent> PROPOSED: Ivan will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.

gkellogg: This worked well.

<manu> +1

<JoeAndrieu> +1

<drummond> +1

<burn> +1

<Dudley> +1

ken: +1

<grantnoble> +1

<rhiaro> +1

<tplooker_> +1

<yancy> +1

<peacekeeper> +1

<brent> PROPOSED: 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.

ivan: I am not opposed. I don't know if I have rights.

<JoeAndrieu> +1

<brent> +1

<rhiaro> +1

<ivan> +1

<burn> +1

<Dudley> +1

<drummond> +1

<tplooker_> +1

<grantnoble> +1

<manu> +0.9

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: We are done with this topic.

Logistics of additional meetings

burn: 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> Link to doodle poll: https://doodle.com/poll/mnru35rtik6mtsxx

JoeAndrieu: This is based on your laptop timezone.

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

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

burn: 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?

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

burn: I want a tradition of no meeting after F-2-F the week after.
... March would be a proposed time for the next F2F.
... Is that too soon or late?

<peacekeeper> 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)

<drummond> +1 to January

<JoeAndrieu> +1 to too late (January better)

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

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

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

JoeAndrieu: I agree.
... The rubric should be ready for review by then.

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

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

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

<ivan> scribejs, set arnaud Arnaud Le Hors

<ivan> guests+ arnaud

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

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

burn: Hosting?

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

selfissued: Last week in Jan is clear.
... MS can get rooms in Redmond, sFO, or London.

ivan: Europe would be fair.

JoeAndrieu: RWOT location is March Beunos Aires.
... Not finalized yet.

burn: Your preference has been noted, Ivan ;)

brent: Webex may need to change machines.
... 1/2 hour break.

<peacekeeper> scribe: peacekeeper

pamela: Microsoft joining the DID WG has been approved. myself and Daniel Buchner will be representatives.

brent: we have a presentation by JoeAndrieu now
... ...to talk about Rubric for Decentralization

JoeAndrieu: 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 includde 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-judgemental. 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.

<ivan> starting slide for Joe's presentation

JoeAndrieu: 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 possibe 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 governened 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.
... questions ?
... or comments ?

burn: "criteria" is plural. "criterion" is singular.

pamela: 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

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

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

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

pamela: how is this relevant for DID methods?

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

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

JoeAndrieu: yes we're going to add more

manu: 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?

JoeAndrieu: 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: this is fantastic

<JoeAndrieu> google doc: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?usp=sharing

drummond: 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

<Zakim> burn, you wanted to ask if a specific goal is to distinguish among all did methods

drummond: neutral parties could evaluate DID methods (e.g. similar to EFF's secure messaging scorecard)

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

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

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

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

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

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

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

JoeAndrieu: 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: so this would be for illustrative purposes on how to use the rubric

<Zakim> JoeAndrieu, you wanted to show the examples in the google doc

pamela: 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

JoeAndrieu: this is up to the evaluator. every evaluator will have to decide for themselves what "inexpensive" means

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

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

drummond: 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

JoeAndrieu: (showing working document in Google Docs)

brent: thanks everybody. moving on to next topic.

Concerns and Requirements for adopting work items

manu: (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: 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.

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

ivan: yes but the main requirement is that all tools are available and set up correctly

gkellogg: 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: moving on to concrete requirements.
... we had consensus that open issues must be preserved. then we can triage and process them.

brent: we're talking about moving from the CCG did-spec repo to the WG repo.

manu: 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?

<Zakim> JoeAndrieu, you wanted to suggest that PRs from non WG members need special handling

JoeAndrieu: 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: 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

<Zakim> burn, you wanted to suggest we stop using the word 'preserve'

burn: 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 th 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

ken: let's distinguish between open and closed PRs.
... let's be clear on what exactly we're moving/preserving/closing/etc.

manu: so what should we do with commit history

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

burn: precise discussion is around "complete commit history must be in WG", rather than "commit history must be preserved".

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

ivan: 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

selfissued: 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> +1 to Mike's point

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

<Zakim> manu, you wanted to note its easy

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

<drummond> Sorry rhiaro

<drummond> Ivan is attending to it again

manu: +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.

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

<Zakim> JoeAndrieu, you wanted to say it isn't about need, it is about the tradeoff for the trouble

selfissued: i haven't heard us talk about editors. there are no editors yet, so they can't be heard.

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

selfissued: what i said was that "editors + chairs + staff work it out" is not possible since there are no editors yet

manu: moving commit history is easy via Git rebase operation

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

<rhiaro> I think it should be available

(5 people raised hands)

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

(4 or 5 people raised hands)

burn: we will select editors at some point

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

<rhiaro> I think closed issues should be available because thoughtful people search existing issues before raising a new one. We might get repeats if theyd on't think to search the old repo

manu: 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

brent: (reading rhiaro 's comment)

pamela: 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> +1 to pamela

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

gkellogg: 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

burn: 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

<Zakim> manu, you wanted to say not stating that anyone has to read all that history (and many don't)... but it's important for some folks.

manu: 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

burn: 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: no, that was a different conversation

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

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

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

<gkellogg> scribe+ gkellogg

DID resolution

<gkellogg> peacekeeper: DID resolution is getting more interest, becuase once you have DIDs, you need to use them.

<ivan> start of presentation slides

<gkellogg> … There are use cases just for identification, but others are meaninless without resolution.

<gkellogg> … It’s the process of getting from a DID to a DID document. Similar to domain-name resolution

<gkellogg> … It’s not a protocol, which is what people usually expect, such as for HTTP. But, it doesn’t work the same way.

<gkellogg> … It’s more like an abstact function or algorithm. The process of how this works is method-specific.

<gkellogg> … Some methods may not require any network resolution, such as peer and key DIDs; resolution involvs constructing an ad-hoc document.

<gkellogg> phila: Can you give examples of read DIDs

<gkellogg> peacekeeper: Sovrign, and others define access that requires a block chain. A resolver would need to interact with that ledger to do the resolution.

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

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

<gkellogg> … Some methods natively store documents, others just store the bits and pieces that make it easy to construct the document.

<gkellogg> … DID resolution is defined to be a process that executes the operations (e.g., read)

<gkellogg> … The CCG has been meeting for a year or so which has resulted in different releases. Not neessarily ready for implementaiton, but is a good start.

<gkellogg> … It’s out of scope for the WG to work on resolution (right now).

<gkellogg> … (examples of how resolution works)

<gkellogg> … Verifying a signature may require DID resolution to discover one of the public keys to use that to verify the proof of the document.

<gkellogg> … Several communities are working on DID-Auth, involving a challenge-response, which is also out of scope for this WG.

<gkellogg> … Resolution required to discover PK as well as other attributes of the DID.

<gkellogg> … DID documents can contain service endpoints for things like security or agents or other ways to ineract with a subject.

<gkellogg> … The DID spec describes the syntax of a DID and DID URLs, including an information space under the DID.

<gkellogg> … Similear 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.

<gkellogg> … If a path is a way of organizing an information space, the matrix parameters are a way of influencing what a DID URL dereferences.

<gkellogg> … We use the URI spec, so we must be careful to align DIDs with that spec.

<gkellogg> … Resolution means determining an access mehanism through which you can interact with a resource.

<gkellogg> … Dereference means to execute an action on that resource.

<gkellogg> … FIrst resolve to know how to interact.

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

<gkellogg> … Mostly, path, query, and fragment are unspecified, so that method developers are free to make use of these URL parts.

<gkellogg> … THe trivial case is a DID itself, which means to retrieve the DID document.

<gkellogg> … Another use case includes a fragment identifier, which would refer to a part of the DID document.

<gkellogg> … The meaning of the fragment is not based on the URI scheme, but based on the MIME type.

<gkellogg> … These are mostly the same as used in HTML and SemWeb (see Cool URLs)

<gkellogg> … It seems useful to have a URL (vs URI) to get a specific resource from a document.

<gkellogg> … Matrix parameters might describe specific versions of documents.

<gkellogg> … (list of matrix parameters)

<gkellogg> … Not a protocol, but an abstract functions which can be realized using different technologies.

<gkellogg> … They way its resolved can influence the results.

<gkellogg> … DIDs may refer to other DIDs or use HTTP-like redirects.

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

<gkellogg> ivan: A flag to ourselves that the DID scheme is currenlty 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.

<Zakim> JoeAndrieu, you wanted to ask if dereferencing should be in scope for the "resolution" spec

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

<drummond> +1 to the DID spec including the registration of the mime type

<gkellogg> phila: 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.

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

WoT joint session.

<gkellogg> hadleybeeman: TAG introduction. We’re interested in seing how youove come along and how we can help.

<ivan> guests+ Hadley_Beeman

<ivan> guests+ Michael_McCool

<gkellogg> mccool: WoT is a WG/CG for around 2 years. THere’s some overlap and potential collaboration.

<ivan> scribejs, set mcool Michael McCool

<gkellogg> … We’re targeting IOT devices applying web architecture to define requirements and supplement IoT for the web.

<gkellogg> … s/mccool/mccool/

<burn> danbri, good point, thanks

<danbri> (there's also an Interest Group since 2019; proposed charter update https://www.w3.org/2019/07/wot-ig-2019.html)

<danbri> (er since 2015, sorry)

<gkellogg> mccool: We have two delieverables, the Thing Description (dataschema for payloads) and an abstraction of how to work with a device.

<gkellogg> … There is a binding to a particular protocol, describes in Binding Templates.

<gkellogg> … The main deliverable is a TD, which as a JSON-LD document.

<gkellogg> … The relevant bit is that we need to identify both devices and users.

<gkellogg> … We’re looking at service directories with access control, and need to identify both users and devices, although this becomes an indirect tracking risk.

<gkellogg> … (could use a device to track a person).

<gkellogg> … IDs could be mutable, but this might complicate other use cases.

<gkellogg> … It seems there’s a lot of overlap with DIDs.

<gkellogg> … There are other related things; a TD describes a single device, there’s also a template that describes generic properties of instances of devices.

<gkellogg> … The device might be private, but the template does not need to be.

<gkellogg> … In our new WG charter we have a long list of things to acomplish, but three of them directly relate to DID.

<gkellogg> … Identity management needs to be done in a way to keep track of devices and owners and assign roles.

<gkellogg> … You might be in a smart home use case where access is uniform, but a smart city might have stronger access control requirements.

<gkellogg> … We’d like to have a consistent way of doing things that addresses the different use cases.

<gkellogg> … In Discovery, we were told by the privacy group that we didn’t have enough pieces together.

<gkellogg> … We don’t have a defined way to get a TD and what its lifecycle is.

<gkellogg> … By discovery, it might a search engine with a set of IPs. both global and local context problems.

<gkellogg> … We’d like to work off of existing work, there may be 2 phases, first contact (opaque and anonymous).

<gkellogg> … Later, authenticate and look for devices.

<gkellogg> … IETF doesn’t take into account privacy sufficiently.

<gkellogg> … We’d like to work on IETF resource directories.

<gkellogg> … 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).

<gkellogg> … We’re still in the stage of defining requirements and scope of existing standards.

<Zakim> manu, you wanted to mention that Identity Management may be Verifiable Credentials + DIDs, Discovery sounds like DIDs, Interop profiles might be Verifiable Credentials and/or just

<gkellogg> manu: Looking at these requiremnts, DIDs are a part of it, but VC might be related too.

<gkellogg> … There are things like object capabilities, authorization capabilities that might fit in.

<gkellogg> … Identify management seems like VC+DIDs.

<gkellogg> … A DID registry might find all DIDs, but not specific.

<gkellogg> mccool: might be two directories.

<gkellogg> manu: The interop profiles are confusing.

<gkellogg> mccool: these are things that are new and challenging. Not everything is relevant to DIDs.

<gkellogg> manu: constantly shifting identifier is challenging.

<gkellogg> mccool: real requirement is privacy. Mutable identifiers is a requirement, otherwise a tracking risk.

<gkellogg> manu: Delegation of authority use cases.

<drummond> +1 to delegation of authority being another DID + verifiable credentials capability

<gkellogg> … People working on object capabilities.

<gkellogg> mccool: I didn’t highlight security issues, but we have somethings OAuth related we’re working on.

<gkellogg> … We need to sort how out to handle HTTPS in a local context, and don’t want to define schemes.

<Zakim> dezell, you wanted to ask about slide 12

<gkellogg> … There are things like ACE and tokens that provide similar capabilities.

<gkellogg> dezell: I’d reather see “identifier management” than “identity mangaement”

<danbri> +1 re identifier management

<JoeAndrieu> +1 for identifier management

<gkellogg> drummond: 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.

<gkellogg> … Those groups would love to talke with you about it.

<gkellogg> … The code-base is at Hyper Ledger.

<gkellogg> mccool: we’re interested in that stuff.

<gkellogg> phila: THe Barcode people would say you don’t need any of that, you already have it.

<gkellogg> tplooker: Cryptography and self-authenticating identifiers could be useful in a TD.

<gkellogg> mccool: we also have security risks on if people fiddle with a TD to point elsewhere.

<drummond> Can Michael share contact info so we can reach him after this session?

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

<gkellogg> mccool: could be pair-wise identifiers.

<gkellogg> burn: (contact info to be sent out)

work through issues

<gkellogg> ivan: Do we have a quarum for making decisions with 7 pro-forma members.

<gkellogg> brent: people can always object.

<gkellogg> subtopic: Use Case issues

<gkellogg> brent: If we want to proceed with an existing issue, we’ll create a new one and point back to the original.

<gkellogg> … issue #2.

<gkellogg> manu: what’s the action?

<gkellogg> JoeAndrieu: I read the issue and link and think we’ve addressed it.

<gkellogg> burn: If the CCG thinks ie can be closed, we don’t need to deal with it.

<gkellogg> brent: issue #3 – long term credentials and timestamps.

<gkellogg> JoeAndrieu: On Ledger there are timestamp attributes you can take advantage of, but we don’t have a use ase.

<gkellogg> … We’ll adopt it in the WG, but we’ll leave it open until it’s done.

<ivan> Use cases' repository

<gkellogg> brent: We’ll bring it over.

<gkellogg> … issue #5 – 10 design goals

<gkellogg> JoeAndrieu: Think it’s resolved.

<gkellogg> brent: issue #6 – differentiate DIDs and DID Documents

<selfissued> Can you post the repository URL again? I'd lost my IRC connection.

<gkellogg> JoeAndrieu: 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.

<gkellogg> ivan: Not a use case issue, but a separate document.

<gkellogg> JoeAndrieu: Sometimes the use case document as about identifying gaps.

<gkellogg> manu: It seems vague; I wouldn’t know what to do.

<gkellogg> brent: I think there’s some value here, and if he things we can do something, we should bring it over.

<gkellogg> JoeAndrieu: This chart (in my head) is going to be a catalyst for controversy. Both good and bad.

<gkellogg> brent: Use cases or another note.

<gkellogg> … We could move the issue over (to WG)

<gkellogg> ACTION: burn to move issue to WG for potential new note.

<selfissued> https://github.com/w3c/did-wg is the overall repository, right?

<selfissued> What are the repository URLs for the deliverables?

<gkellogg> brent: issue #10 – portability/substitutabiliy

<gkellogg> JoeAndrieu: 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.

<gkellogg> brent: We’ll move it over.

<gkellogg> subtopic: spec issues

<gkellogg> brent: issue #82 – Fragment identify semantics

<gkellogg> … We may determine that the CCG triage is not what we’d do.

<gkellogg> manu: We should pull this in. Not editorial.

<gkellogg> manu: We’re trying to say that frag identifiers are associated with the mime type.

<gkellogg> ivan: It may be that the fragment identifier is defined for the JSON-LD type.

<manu> 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> gkellogg: I'd say it's done, if not, it should be an action to refer to JSON-LD group.

<gkellogg> peacekeeper: It sounds like the DID doc is defining fragment semantics for a DID scheme, but it shouldn’t do that.

<gkellogg> ivan: issue should be brought over.

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

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

<Zakim> JoeAndrieu, you wanted to ask about CCG did-spec issue management

<gkellogg> brent: issue #112 – intro is incorrect

<gkellogg> … Done, close

<rhiaro> brent, hang on, not necessarily addressed maybe just mentioned as 'towards'

<rhiaro> I think most that got 100% addressed were closed

<rhiaro> okay never mind this one was addressed

<gkellogg> brent: at 4:30 people from PING coming to discuss our relationship.

<gkellogg> ivan: There has been a lot of discussion on horizontal review that groups get there too late.

<gkellogg> … When we have FPWD, we should let them know it’s there for them to look at.

<gkellogg> … Also, PING, I18N and Accessibility have forms for us to consider.

<gkellogg> … There’s a lot to look at, but much is irrellevant. We should not wait for CR, but do way before.

<selfissued> It is time

<selfissued> scribe+

<selfissued> brent: Making the homepage more visitor-friendly is one possible topic

<selfissued> brent: We could discuss DID Controller - proposed by Joe

<selfissued> JoeAndrieu: DID Controller is related to DID Authentication

<selfissued> Joe: There was a question on the CCG mailing list about the Controller property and the Authentiation property

<selfissued> ... He didn't make it through understanding the relationships

<selfissued> JoeAndrieu: asked Marcus about it

<selfissued> Marcus: there are multiple ways of seeing it and different views

<selfissued> Marcus: There are many DID methods that don't use the DID document

<selfissued> Marcus: There isn't a method-independent interpretation

<selfissued> JoeAndrieu: There was a discussion between Sethi Shivam and Daniel Hardman

<selfissued> JoeAndrieu: The spec text is not aligned with what most people think it should mean

<selfissued> burn: If it's not in the authentication section of the document, where is it?

<selfissued> manu: Some methods will use the Authentication section to allow you to update the document

<selfissued> manu: Other methods may do something totally different

<selfissued> manu: This is old text that is wrong and needs to be updated

<selfissued> JoeAndrieu: The keys that can be used to update can be used to impersonate

<selfissued> manu: In veres1, DID documents are capabilities

<selfissued> manu: In veres1, different keys are used to update the document

<selfissued> manu: Will open an issue

<selfissued> Marcus: The name of the top-level property is Controller, whose value may be another DID

<selfissued> manu: The Controller field tells you what DID controls that document

<selfissued> manu: This could be used by organizations

<selfissued> JoeAndrieu: For BTCR, the Controller would be ignored

<selfissued> burn: It's not clear to me what the difference between Control and Authentication is

<selfissued> JoeAndrieu: Whoever controls the document is omnipotent for all content in the DID document

<selfissued> JoeAndrieu: The Authentication section specifies the mechanism for authenticating as the DID - a legitimate claimant to act as a subject of the did

<selfissued> JoeAndrieu: ... so that entities using that Authentication mechanism can use the DID for DID auth, but can't necessarily change the DID

<selfissued> burn: We talk about who proves control over the did by authenticating to it, not by being the controller

<selfissued> JoeAndrieu: We have a limited authorization to authenticate on behalf of the DID

<selfissued> JoeAndrieu: These semantics are confusing

<selfissued> selfissued: Is the terminology in the document currently contradictory and confusing?

<selfissued> brent: Yes

<selfissued> JoeAndrieu: There's a distinction between who can change the DID document and who can authenticate as it

<selfissued> burn: Asked in one case whether the party is a controller or an authenticator

<selfissued> JoeAndrieu: Related to subject versus holder

<selfissued> JoeAndrieu: Sometimes they are the same - sometimes they are not

<selfissued> brent: In the subject versus holder debates we had two terms

<selfissued> JoeAndrieu: A possible term is governor

<selfissued> burn: The term DID Subject makes sense to me

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

<selfissued> ivan: I don't like the term DID Document Controller

<selfissued> selfissued: What are the next steps to resolve this?

<selfissued> Brent: Wanted to ask the same thing

<selfissued> Brent: We've created several issues. Manu, can you point us to them?

<selfissued> manu: They are issues #2 and #3

<manu> Created two new issues: https://github.com/w3c/did-spec/issues/2

<manu> ... and https://github.com/w3c/did-spec/issues/3

<selfissued> Drummond: If we use DID subject as the entity identified by the DID, the other two roles have to be named

<selfissued> Drummond: The entity the proves control of the DID document

<selfissued> Drummond: The entity that can authenticate that it has control of the DID

<selfissued> Drummond: The entity that controls the document could be one of the parents - the other could be the other parent

<selfissued> Drummond: I'm not suggesting terms for the other two

<selfissued> Marcus: My assumption in the DID spec is that we are mostly defining things that are method independent

<selfissued> Marcus: The controller construct doesn't make sense for BTCR

<selfissued> Marcus: ... how to log into a Web Site with a DID

<selfissued> brent: We're going to pause that conversation now for the PING discussion

<selfissued> brent: I've been working in the PING for a while

<selfissued> brent: A difficulty of the work is connecting with the working groups to provide timely, actionable feedback

<selfissued> brent: We want to know who you are and how to best work with you

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

<burn> Tara Whalen, PING co-chair

<ivan> guests+ Tara Whalen

<ivan> guests+ Christine Runnenger

<selfissued> brent: Our primary recommendation is to define Decentralized Identifier

<selfissued> brent: Identifiers that don't require association with a centralized party

<drummond> Identity, security, and privacy are the holy trinity of the Web.

<selfissued> brent: You can prove control of them independent of third parties

<selfissued> brent: There's the DID, the DID Document, and DID Methods

<selfissued> drummond: I work in one of the companies in the space

<selfissued> drummond: DIDs are foundational technology for privacy by design at Web scale

<selfissued> drummond: Architecture supports the range from public to pairwise

<selfissued> drummond: It's useful talking about the relationship between DIDs and Verifiable Credentials

<selfissued> manu: PING came into Verifiable Credentials late

<selfissued> manu: The larger ecosystem is Verifiable Credentials

<selfissued> manu: We want people to be able to go organizations and get credentials from them and share them where they choose

<selfissued> manu: Correlation is an issue

<selfissued> manu: Question is how correlatable is the identifier

<selfissued> manu: There are currently 30 types of DIDs

<selfissued> manu: These are about the identifier

<selfissued> manu: Cryptography lets you do authentication and know who you are talking to

<selfissued> manu: We all care deeply about privacy

<gkellogg> ack: manu

<Zakim> manu, you wanted to elaborate on privacy elephants in the room. :)

<selfissued> manu: Is there a way to shift where your information is stored, putting the individual in charge?

<selfissued> manu: With their software helping them make better privacy decisions

<selfissued> manu: DIDs can be like super tracking cookies

<selfissued> manu: Over their lifetime, the people they share them with can do correlation behind the person's back

<selfissued> manu: There are zero-knowledge proofs being used with Soveriegn

<selfissued> manu: The feedback that the WG would like from the PING is what privacy issues they see

<selfissued> burn: We had an intention that these identifiers would be reasonably cheap and easy to create

<selfissued> burn: There are use cases where you'd use different identifiers

<selfissued> Dan: If to sign in, I have to demonstrate that I'm over 18...

<Zakim> burn, you wanted to give guardianship or prison example

<selfissued> Tara: It's good to hear that there are many security and privacy engineers working on this

<selfissued> Tara: It's good to give us information early

<selfissued> Tara: You seem to be miles ahead of some of the other groups

<selfissued> Tara: Where are you in the process?

<selfissued> Dan: We are not yet at first public working draft

<selfissued> Brent: We selected what will become our first editor's draft yesterday

<selfissued> Christine: It's apparent to me that you're early in the process

<selfissued> Christine: Thank you for reaching out early

<selfissued> Christine: Look at the updated security and privacy questionairre

<selfissued> Christine: You're in the best position to decide when you need input from us

<selfissued> Christine: For instance, ask us to look at specific issues in GitHub

<selfissued> JoeAndrieu: There are specifications for DIDs and method specifications

<selfissued> JoeAndrieu: We'll be enabling self-tests

<selfissued> Christine: Is what Joes was describing like a profile?

<selfissued> selfissued: (the question wasn't answered)

<selfissued> ivan: Many of our use cases are different than others you may be familiar with

<selfissued> drummond: The specification we're chartered to do creates a new kind of URI - a DID

<selfissued> drummond: Explained the syntax of a DID URI

<selfissued> drummond: There's an informal registry that the Credentials Community Group maintains of DID types

<selfissued> Every DID method can define its own protocol

<selfissued> selfissued: What are the privacy implications of each DID method defining its own protocol

<selfissued> drummond: Every DID method will have to have its own privacy analysis

<selfissued> drummond: The spec is already the result of three years of work

<selfissued> drummond: It's a requirement on DID method specifications that they have a Privacy Considerations section and that they address certain things

<selfissued> drummond: It would be good to have PING review these guidelines

<Zakim> manu, you wanted to note that the mistake we've made before is treating the spec/feedback as an isolated thing... it's not, it's part of a larger ecosystem and we need to figure

<selfissued> manu: A mistake we've made in the past interacting with PING is isolating the conversation to the spec we're working on

<selfissued> manu: Data models don't have the same privacy implications as protocols

<selfissued> manu: We need to discuss the ecosystems wholistically

<selfissued> manu: We could say "it's just an identifier" but there's a larger usage context with privacy implications

<selfissued> manu: Can we tag our issues with a privacy tag to help you when you use our GitHub issue tracker?

<selfissued> manu: Or is there a more effective way to work?

<selfissued> Christine: Tagging issues would be fantastic

<selfissued> Christine: The W3C staff need to use some machinery to create the tag

<selfissued> Christine: You could appoint Brent as your PING liaison

<selfissued> ivan: Is this mechanism already operational?

<selfissued> ivan: There are special labels that you can add that will ping PING

<Zakim> drummond, you wanted to ask PING about their scope and what they might be able to help us with

<selfissued> drummond: Sovereign spends a lot of time on privacy

<selfissued> drummond: DIDs and Verifiable Credentials used well are the basis of Privacy by Design at Internet scale

<selfissued> drummond: We'd like to examine separately from our spec the use of DIDs to create an ecosystem

<selfissued> drummond: Used wrong, DIDs can be the greatest tracking cookie ever

<selfissued> drummond: Used right, they can be a solution to surveilance capitalism

<selfissued> Christine: I worry that DIDs could be used for evil

<selfissued> Christine: You appear to be catering for the use case of a globally unique persistent identifier

<selfissued> Christine: It might be worthwhile having a chat with the Security working group

<selfissued> drummond: Security, privacy, and identity are a triangle

<selfissued> drummond: The Security Considerations section is also quite long

<selfissued> Brent: Thank you very much for coming!

<selfissued> Christine: Did the community group produce a Use Cases document?

<selfissued> drummond: Yes - and it's a good one

<selfissued> JoeAndrieu: Feel free to reach out to me about it

Open topics

<selfissued> Brent: We can switch back to open topics now

<selfissued> JoeAndrieu: I think that third role may be acting on behalf of the DID: A term could be DID Actor

<drummond> +1 to DID actor

<selfissued> JoeAndrieu: Or it could be DID User

<selfissued> Dan: Drummond used an example of a child and two parents. I care a lot about the guardian use case.

<selfissued> Dan: There are cases where someone else has some of the rights of a person on their behalf

<selfissued> Can: There are also the courts, which can change those relationships

<Zakim> manu, you wanted to raise larger issues? and to work mode and to work mode for editors and to discuss umm, who are the editors :P

<selfissued> Dan: We should have an example illustrating these use cases

<drummond> Reminder to talk about several examples of the 3 roles

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

<Zakim> deiu, you wanted to talk about actor and delegation

<selfissued> deiu: We speak of delegator and delegate. Actor would be confusing to many people.

<selfissued> selfissued: +1 that "Actor" is overused and confusing

<selfissued> drummond: There's agreement that three terms are needed

<selfissued> drummond: We should all take the action item to think about this and possibly take it to the list

<JoeAndrieu> +1 delegate

<selfissued> Brent: We have two issues about this - #2 and #3

<selfissued> Brent: Should the issues be updated to talk about the three roles?

<selfissued> manu: Yes

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

<selfissued> Dan: Let's get other possible topics out on the table

<selfissued> Dan: One is external communications

<selfissued> Dan: Such as who are the editors

<Zakim> manu, you wanted to who are the editors :P, work mode for editors, and to raise larger issues. and to note that we're bikeshedding names now

<selfissued> Manu: It would be good if the editor's were given free reign to clean up the spec

<selfissued> manu: There are larger issues that might help the editors work faster

<selfissued> manu: Some things could be ripped out

<selfissued> manu: What do we think we can rip out before we start adding stuff?

<drummond> +1 to the editors being assigned to do a cleanup pass

<selfissued> Brent: The three CCG members who have edited the CCG spec are Manu, Drummond, and Marcus

<selfissued> Brent: Do you all want to continue editing and do even more work than before?

<drummond> Yes, I am indeed married to this spec :-)

<selfissued> Brent: All three will continue as editors

<selfissued> Dan: We are lookign for people who will do the work

<selfissued> Dan: We may adjust the editors as we see other people contributing

<selfissued> Dan: We have new people and organizaitons that weren't involved in the CCG

<selfissued> Dan: Please come talk to us if you want to be considered as an editor

<selfissued> Dan: We're paying attention to who's doing the work]

<selfissued> ivan: All the repositories have separate teams that have write and administrator access

<selfissued> ivan: Editors could directly commit

<selfissued> selfissued: We should always use PRs to enable working group review

<selfissued> manu: We should add Amy as an editor. She'll be doing the work anyway and should get credit for it.

<selfissued> drummond: Amy did outstanding editorial work

<selfissued> Brent: The chairs will have a conversation about that

<selfissued> Dan: If the editorial team gets large, there's an interesting question about editorial decisions are made

<selfissued> Dan: Four is a really large group for active editors of a spec

<selfissued> Marcus: I would have also proposed Amy

<selfissued> Marcus: In the CCG, we always created PRs and had editors approve it

<selfissued> JoeAndrieu: I also want to endorse Amy

<selfissued> Joe: If four are too many, you should consider which of you are willing to give up your spot for Amy

<selfissued> Gregg: It's typical to also list Authors as well as Editors

<drummond> And that means Amy is the Red Queen, right? ;-)

<selfissued> Dan: Are all the editors expecting to do editing work or just contributing content?

<selfissued> ivan: What about editors for the Use Cases document?

<selfissued> Brent: Joe, will you continue?

<selfissued> JoeAndrieu: Yes

<selfissued> JoeAndrieu: And I'd like a partner in crime

<drummond> +1

<selfissued> ivan: Phil Archer may want to be a Use Case editor

<selfissued> Brent: Editors for the Rubric

<selfissued> JoeAndrieu: Point of order: We do not yet have a Rubric work item. We should defer until we do.

<selfissued> manu: A lot of the CCG work lately has been working on the charter

<selfissued> manu: Over the past two years things have changed in implementations that have not been tracked by the specification

<selfissued> manu: An editorial pass seems necessary

<selfissued> manu: For instance, the conversations about did:web put off editorial work

<selfissued> manu: It's mostly to remove things that no longer apply

<selfissued> selfissued: Changing spec features and normative behaviors is not editorial

<selfissued> drummond: We deprioritized some of the change requests that were coming in

<selfissued> Brent: I would want to know very explicitly what the scope of the work is that the editors propose

<selfissued> Brent: Our first act with the document shouldn't be to cut massive sections out

<selfissued> Dan: Minor cleanup that's actually editorial is fine

<selfissued> Dan: It doesn't matter that people in the CCG said that changes should happen. They didn't appear in the document that they produced.

<selfissued> Dan: One of the biggest risks for groups is editors making changes that people don't feel were agreed to

<rhiaro> 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)

<selfissued> Dan: Not all the people who are editors are experienced W3C Recommendation Track spec editors

<rhiaro> (in answer to the question why weren't these done already)

<drummond> +1 to Amy's point

<selfissued> Amy: There are a number of editorial cleanups that we didn't have time to get to

<selfissued> Brent: One of the first "editorial" issues we looked at today wasn't actually editorial

<Zakim> rhiaro, you wanted to say there are still a lot of editorial issues, mostly around the overview and introductory sections

<selfissued> Dan: We need to be careful

<brent> selfissued: one of the best practices we instituted was making sure each PR has an issue

<brent> ... I would propose we adopt that working mode

<Zakim> manu, you wanted to say sounds like we're going to go into "slow painful PR mode" :) -- which is fine, but was hoping to move faster.

<ivan> scribe+ brent

<drummond> +1 to Mike's point

<brent> +1 to mike's point

<selfissued> selfissued: WebAuthn and FIDO2 require that issues be created before PRs are created. I request that we adopt that working mode.

<selfissued> manu: PRs can describe themselves without having an accompanying issue

<selfissued> Dan: Going into Manu editorial mode may not be the right way to start off the working group

<selfissued> Marcus: There are several events in the near future that we could use for editing and triaging - such as IIW

<Zakim> drummond, you wanted to talk about roadmap and terminology

<selfissued> Drummond: +1 to what Marcus said

<selfissued> Drummond: I agree with what Mike said

<selfissued> drummond: We should develop a working-group wide ethic of raising issues, discussing them asynchronously, with an eye towards coming to closure

<selfissued> drummond: Terminology is not purely editorial

<selfissued> drummond: We should discuss terminology early to avoid having it slow us down later

<selfissued> drummond: We should start talking about a roadmap and plan of attack for the next few months. We're not starting from scratch.

<selfissued> drummond: We should try to understand early what the real issues are

<Zakim> burn, you wanted to talk about working mode

<selfissued> Dan: We haven't talked about what the process is for deciding when something's ready to go in

<selfissued> Dan: One of the strengths of W3C is that we don't have a formal process for making changes

<selfissued> Dan: There's a principle that there's always a double-check

<selfissued> Dan: The editors have a special responsibility to make sure that they only agree to truly editorial changes without working group review

<Zakim> manu, you wanted to be careful about IIW -- non-WG members contributing/participating...

<selfissued> Dan: 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.

<selfissued> Dan: We can also schedule ad hoc calls, if necessary

<selfissued> Dan: We want the minimum amount of process that will result in good results

<selfissued> Dan: 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.

<selfissued> Dan: There are things we need to be aware of

<Zakim> manu, you wanted to say be careful about IIW / non-member participation

<selfissued> Dan: We want to make sure that things like that don't happen

<selfissued> selfissued: I assume that IIW what we'd do is create issues and PRs - not do editing

<selfissued> Dan: Ad hoc F2F meetings are generally frowned upon

<selfissued> Dan: But people in the same space are clearly free to talk about things

<selfissued> Dan: W3C requires 8 weeks notice before a F2F meeting

<Zakim> deiu, you wanted to mention transparency

<selfissued> Dan: Talking as individuals is always fine - it's just not a working group meeting

<selfissued> Dan: Individuals can always create issues and PRs

<selfissued> drummond: I think that's what Marcus meant

<selfissued> ivan: It would good if this group had a regular outreach to the outside world

<selfissued> ivan: Twitter, Facebook, blogs, etc.

<selfissued> ivan: W3C's blog is open to WG chairs

<burn> I would *love* to delegate blog summaries to someone else :)

<selfissued> ivan: At least once a month it would be good to have communication

<selfissued> Marcus: There are several of us who go to many events and can publicize our work

<selfissued> Drummond: We have two sessions tomorrow

<selfissued> Drummond: Helen is here to do the non-technical version of DIDs

<selfissued> drummond: SSI Meetup is asking for a report

<selfissued> drummond: Is doing a Webinar on Friday

<selfissued> drummond: They want to do a "DID Report" on a regular basis

<selfissued> Helen is at 11:00

<selfissued> drummond: The second is DID Q&A at 4:30

<selfissued> drummond: It's a Q&A with us as WG members

<Zakim> JoeAndrieu, you wanted to mention IDPro article

<selfissued> JoeAndrieu: I'm on the hook for an article for IDPro

<selfissued> JoeAndrieu: I'd love to have some help

<selfissued> Ken: In the AC meeting we had a report from the Web of Things on their interactions with us

<selfissued> pamela: How long will it take for the editorial triage to happen?

<selfissued> pamela: Do I wait to review the spec until after that or do it it now?

<selfissued> drummond: Go for it - read it now

<selfissued> Brent: Thank you for two days of hard work!

<selfissued> manu: Thank you to the chairs

- DRAFT -

DID Working Group F2F in Fukuoka — Second day

17 Sep 2019

Attendees

Contents

Test suite

Logistics of additional meetings

Concerns and Requirements for adopting work items

DID resolution

WoT joint session.

work through issues

Open topics

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output