<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.
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
+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.
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.
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
<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.
<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)
<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
<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
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/RDFA/RDFa/ Succeeded: s/self-issued/selfissued/ Succeeded: s/Amerstdam/Amsterdam/ Succeeded: s/joe, FYI, "criteria" is plural and "criterion" is singular . . . :)// Succeeded: s/methods/the rubric/ Succeeded: s/purposed/purposes/ Succeeded: s/remidation/remediation/ Succeeded: s/mcool/mccool/ Succeeded: s/CRS/CR/ Succeeded: s/Making the/brent: Making the/ Succeeded: s/We could/brent: We could/ Succeeded: s/DID Controller/JoeAndrieu: DID Controller/ Succeeded: s/verus1/veres1/ Succeeded: s/verus1/veres1/g Succeeded: s/Dan:/burn:/g Succeeded: s/Soveriegn/Sovereign/ Succeeded: s/Andre:/deiu:/ Succeeded: s/workign/working/ Succeeded: s/Track spec issues/Track spec editors/ Succeeded: s/was editing the spec/was editing the spec, at Manu's direction,/ Present: ivan rhiaro Kangchan_ burn brentzundel manu grantnoble peacekeeper ken gkellogg tplooker phila Dudley_Collinson yancy drummond igarashi JoeAndrieu jay Kaz_Ashimura gannan Joe_Andrieu dezell selfissued deiu Ken_Ebert Regrets: ivan Found Scribe: ken Inferring ScribeNick: ken Found Scribe: peacekeeper Inferring ScribeNick: peacekeeper Scribes: ken, peacekeeper ScribeNicks: ken, peacekeeper Agenda: https://tinyurl.com/didwg-tpac2019-agenda WARNING: Could not parse date. Unknown month name "09": 2019-09-17 Format should be like "Date: 31 Jan 2004" WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: burn WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]