DID WG (Virtual) F2F, 1st day — Minutes

– DRAFT Minutes –

Date: 2020-06-30

See also the Agenda and the IRC Log

Attendees

Present: Christopher Allen, Ivan Herman, Daniel Burnett, Phil Archer, Charles Cunningham, Chris Winczewski, Justin Richer, Paul Madsen, Dirk Balfanz, Manu Sporny, Drummond Reed, Joe Andrieu, Kyle Den Hartog, Eugeniu Rusu, Brent Zundel, Tim Cappalli, Kaliya Young, Markus Sabadello, Dmitri Zagidulin, Adrian Gropper, Amy Guy, Wayne Chang, Orie Steele, Oliver Terbu, Jonathan Holt, Michael Jones

Regrets:

Guests:

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Manu Sporny, Wayne Chang, Dmitri Zagidulin, Amy Guy, Markus Sabadello

Content:

Ivan Herman: Session slides: https://tinyurl.com/y87mqtlf

Brent Zundel: Welcome everyone to the DID WG – going to go over Agenda, IPR, then set stage for status of deliverables, timeline.
… We’ll be meeting until 10am-1:30pm ET today
… tomorrow we’ll be starting at 12pm ET
… We have breakout rooms here – https://zoom.us/j/91515310373?pwd=WVF0T1Jrc0Nwazl3TUZhYU85dUEyZz09
… We abide by the W3C Patent Policy here - only people/companies listed can make substantive changes to specs we’re writing, please follow W3C Code of Conduct.
… which basically boils down to “be nice to each other”
… We’re going to go over logistics, use cases, break, rubric and implementation guide.
… Please add your name to scribes if you can scribe… you can use queue via “q+” – use the queue if things get crazy.
… keep your comments brief
… helps scribes if you use the queue.
… make sure to ‘present+’ yourself.
… over to Dan.

Daniel Burnett: Usually, we have an introductions section – but we’re not doing that today because we are short on time…
… our mission is to “… standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.”

Daniel Burnett: Named deliverables in the charter
… Decentralized Identifiers v1.0 – Almost all major issues resolved, lots of little stuff
… We’ve gotten pretty far w/ major issues… lots of little stuff left, definitely not done, more than 50 issues left.
… We still have a bit more to do, major issues have been resolved.

Daniel Burnett: We have a couple of other notes that are optional.
… Decentralized Identifier Use Cases v1.0 – Close to done.  Maybe today?
… It would be nice to get done or close to done on that document. The group has been pretty clear on it’s understanding on what DIDs are and what they do.
… With respect to Decentralized Characteristics Rubric v1.0 – Nothing yet. We will discuss today. – what does “Decentralized” mean?
… at time, we concluded that there were different definitions… we wanted to come up with questions that you should ask yourself in order to understand how “decentralized” a particular item is for your use case.
… Goal is not to provide answer, but to provide questions… what needs to be considered. Haven’t begun that work yet, even though there is preliminary work elsewhere.
… There is another deliverable that’s important – Test Suite and Implementation Report – There are some tests, but we have not yet SERIOUSLY begun.
… Any questions?

Manu Sporny: there are also the did spec registry documents

Daniel Burnett: you’re right. these are the items that are in the charter. We should have added some more bullet pts for other ot he documents, such as the DID Registry Spec

Daniel Burnett: If it becomes relevant, we can bring it up - we’ve made good progress on that… progress on that document allowed us to resolve big sticking points in specs.
… That document contains a collection of registries, not just one - we seem to be winding down on what belongs in that document… which registries belong in that document. Obviously, people can keep adding items to that registries document… that document is in pretty good shape right now… good examples, fuller information on alternate representations, JSON-only, and CBOR.
… We’re going to be talking about that during this meeting.
… We are still in Working Draft stage, does not imply consensus.
… Next stage is Candidate Recommendation (CR) – Entry - to publish as CR, the document is expected to be feature complete, have had wide review, and must specify the implementation requirements needed to exit.
… anyone that might have significant opinion should have had opportunity to comment, haven’t started wide review yet… need to specify requirements in order to exit CR stage.
… To exit, you have to satisfy requirements, multiple independent implementations.
… This is why test suite becomes important… you don’t need test suite to exist in order to get to CR.
… Our goal is to ensure test suite is as ready as possible before we enter CR, ensure little delay for implementers to check implementations against test suite.
… To go from CR to PR, you can’t make any substantive changes… you can say features are at risk to prevent that… concern that there might not be sufficient implementations… this feature will be removed if we don’t get sufficient implementation reports. if you have warned about a feature at risk, then feature can be removed in switch to PR… but any other unplanned substantive change (change to implementations) then you have to issue another CR

Manu Sporny: or go back to WD stage.

Daniel Burnett: We work pretty hard to make sure we think document is good and ready short of any feedback we might receive from implementers.
… Exit - to exit CR (and move to PR), the document must satisfy the stated implementation requirements; it must also not have made any substantive change not warned about upon entry
… Going to Proposed Recommendation (PR)…Basically a one-month sanity check during which the AC is encouraged to have any final review and discussion, but if anything major happens it’s a fail (requiring a move back to CR or earlier)
… We go to a large amount of effort to make sure we won’t fail… 30 day clock typically, then it becomes a Recommendation. Still possible to do Errata after that.

Ivan Herman: It’s a six week clock now instead of 30 days, because of Covid situation

Daniel Burnett: There is a pretty picture of the process here – https://www.w3.org/2019/Process-20190301/#recs-and-notes
… We were chartered for 2 years, starting last year… in August 2021, we’re done unless we’re extending charter… that requires approval by W3C Members – need a very good reason or big support.
… We counted backwards to get to dates we need to hit.
… In order to finish by August 2021, we need to have PR by July, which means CR2, CR2 by March 2021, CR1 Nov 2020.
… This is not a get out of jail free card… “it’s not really a CR” – no, we are absolutely convinced by Nov2020 of this year… and then oops, we missed something, so we had to do another one. If we do that, we’re still fine, still fit within timeframe. We need first CR by this year.
… Targeting feature freeze by May 2020… not feature freeze yet… at very end of June, that’s ok, we have addressed major topics and cleaned minor ones along the way. Chairs will be calling for feature freeze very very soon.
… Why are we going to be pushing so hard for feature freeze… if spec isn’t ready, it isn’t ready, but if we want to hit our timeline, we need to get to feature freeze soon.
… The goal of this meeting is to GET TO FEATURE FREEZE… :)
… If you have something new that isn’t in the spec and there isn’t an issue, then very soon, we’re going to disallow new items like that. Any questions?

Manu Sporny: Silence

Daniel Burnett: There is a precise list of things that needs to happen to get into CR, we’ll put that list together when group agrees on feature freeze.

1. Use Cases

See slides

Phil Archer: Dan said use cases might be done on this call, I think we’re close, still need a few weeks of work.
… As I hope everyone on call is aware, use case document that Joe and I are working on, adaptation of one worked on in CCG by Kim and Adrian… we did get FPWD out in Nov last year as Charter asked us to do.

Ivan Herman: See editor’s draft of the Use Case document

Phil Archer: Because this work is not starting from nothing, it would’ve been unhelpful if we couldn’t talk about DIDs and DID Docs and things that underpin core work. We do say early on, we are not starting from scratch, but these are use cases that underpin it all.
… We didn’t want to put solution before the problem, a bit of a balance between those two, we know the space we’ve been working in…
… We’re trying to go from there.
… Original document from CCG - 4-5 focal use cases, they are still in doc, but have been amended. There was one that had solutions everywhere, etc… new section that not was in original, short use cases, 1-3 paragraphs long, a bunch of short use cases that Joe and I have curated, but not written by us.
… One of the problems we’ve had throughout the document is making sure use cases demanded existence of DIDs and functionality and not automatically going into VCs… make sure use cases are not VC use cases. I think we’ve succeeded, VCs are a use case, but making document stand on it’s own, DIDs have purpose in absence of VCs have a purpose.
… We’ve been chatting our way through it… short list of issues outstanding that we can’t resolve betwene ourselves, want to focus on that today.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/2

Phil Archer: Issue 2 Need to add coverage of portability/substitutability Left over from CCG – Propose: close (overtaken by events)

Daniel Burnett: One of my favorite phrases => overtaken by events

Manu Sporny: The initial goal here was to ensure that the identifier that a VC used was portable… for example, portability of a DID.

Joe Andrieu: What does portability mean? Is there some way that I can take a DID in one ledger and get it into another ledger. That’s why this isn’t written up yet.
… I don’t think it’s in the use cases, but adding it to ticket.

Drummond Reed: I thought portability of data - move portability of blog from one provider to another.

Phil Archer: Would be good to get something from you Drummond.

Dmitri Zagidulin: re what joeAndrieu said, this issue is related: https://github.com/w3c/did-core/issues/33

Dmitri Zagidulin: Glad Joe brought up portability of DID Document itself, if that’s in scope, related issue 33 on DID Core – “sameAs” property.

Oliver Terbu: +1

Drummond Reed: +1

Dmitri Zagidulin: How do we link one DID Document to another, both represent the same subject in preparation for migration. Relevant topic, relevant to use cases, whether or not it should be in DID Core is the controversial bit, different views there. We need the linking to DID Document sameAs functionality in order for DID Document to be portable.

Manu Sporny: I think the original intent of the portability issue was lowercase-p portability
… not necessarily full equivalence “move the DID from one ledger to another” use case
… and I fully admit that all of these are portability use cases, and we’ll just have to figure out where we’re drawing the line (or if we are)
… it’s a pretty deep rabbit hole to go down. And we’ll have to figure out where to stop, at least for this version of the WG
… and I’m sure as you and Joe have discussed, there are various ways to document the use cases (but not solve/implement)
… so, basically, it was supposed to be the easy portability problem

Phil Archer: yes, we need a bit of text that hints at those use cases, but we don’t need to go into great depth.

Drummond Reed: Dmitri is right on, I’m working on PR for sameAs property… would like Dmitri to work with you on that.

Joe Andrieu: Let’s move this to issues… need to get through rest of stuff.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/14

Phil Archer: Issue 14 What does it mean for a DID to be “recorded in a registry”? Mike raised this, Joe and Manu have discussed, DaveL supports…

Joe Andrieu: We refer to DID Registries as where you go to do resolution… but some DID Methods, resolution is baked into DID itself, there really isn’t a separate registry… however, we also have Verifiable Data Registries, different beast, we call them both registries… we’ve cleaned up language in use case document, when we use registry, we mean it for DIDs that use a registry, not all DIDs use a registry.
… We might be clear in use cases, not in DID Core, uses may be compatible.

Dmitri Zagidulin: I like what Joe said – proposed we resolve this - if this is controversial, similar interpretation - since we talk about CRUD operations on DID Documents, create, read, wanted to propose, recording DID in registry… talk about it.

Phil Archer: Under action on Create, that’s what we talk about.

Drummond Reed: We’re taking comments on PR for terms - only use verifiable data registry, that’s what we’re using now, don’t use “registry” by itself, only call it VDR.
… You are either using one or you’re not, that’s all.

Markus Sabadello: Dmitri and drummond said what I already wanted to say - create operation applies to every DID and DID Method… don’t have to think registry, ledger, etc… DIDs can be created and resolved.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/39

Phil Archer: Use Case issue 39 is a duplicate of core issue 248. Need term for relying party
… What do you call a relying party?

Ivan Herman: see related issue in Core

Dmitri Zagidulin: +1 to ‘Requesting Party’.

Phil Archer: I wrote out history – I believe there is consensus around Requesting Party - people commented are content with that, no strong objections to that.

Phil Archer: any objections?

Markus Sabadello: I didn’t understand this issue, You have to say what action you’re thinking about… someone who resolves the DID, someone trying to authenticate DID Controller, someone requesting proofs/claims… what is this entity/actor doing?

Justin Richer: I haven’t dug into the text of the issues… but did want to point out that Requesting Party is used in UMA protocol.
… Want to make sure Editors were aware of it’s use in different but related space.

Phil Archer: We have jumped around trying to think of alternatives… “Brandishing Your DID” was put forth briefly chuckles.

Drummond Reed: We might want to use Verifier – consistent with both specs…

Brent Zundel: -1 for verifier

Phil Archer: We looked at it, it was shot down.
… It sounds as if we have to come up with something, where someone is making use of DID in particular way
… It’s difficult, we’re searching around for a term that doesn’t reuse something someone else is using, finding it difficult to find a word here.
… nearest I can come to is Requesting Party unless someone has an objection.

Drummond Reed: I don’t have a strong objection to “Requesting Party”. I’d prefer “verifier”, but “Requesting Party” is okay.

Adrian Gropper: I introduced the term, I did it explicitly because Requesting Party was defined adequately in UMA - giving proxy to Justin, no way want to insist on Requesting Party, if we have consensus, great.

Ivan Herman: Just want to say that this is a NOTE, not a REC, so we can go the other way, leave it as is, put a note to make it clear that term is used in loose way.
… Then we should move on - have DID Core define it…

Oliver Terbu: +1 requesting party

Orie Steele: +1 to Requesting Party

Phil Archer: Then we can’t finish until DID Core until that’s done. Let’s see if we can get Requesting Party done.

Drummond Reed: I’d be fine w/ Requesting Party –

Phil Archer: PROPOSED RESOLUTION: That we use the term “Requesting Party”

Kyle Den Hartog: +1

Orie Steele: +1

Manu Sporny: +1

Ivan Herman: +1

Dmitri Zagidulin: +1

Drummond Reed: +1

Joe Andrieu: +1

Daniel Burnett: +1

Phil Archer: +1

Adrian Gropper: +1

Wayne Chang: +1

Amy Guy: +1

Brent Zundel: +1

Joe Andrieu: minor clarification: We’ll use the term “requesting party” to refer to the party who uses a DID for any purpose.

Resolution #1: That we use the term “Requesting Party”

Ivan Herman: https://github.com/w3c/did-use-cases/issues/75

Phil Archer: Issue 75 We are doing an auto-inclusion of glossary from DID-Core. Amy has done a lot of work on this lately, couple of references outside of that document, messing things up.
… do we fix those errors - which we hope will make the filter mechanism work - or take a snapshot and allow a delta with “the core spec is normative” warning?

Amy Guy: phila, I raised this on drummond’s recent terms PR

Manu Sporny: it’s just a simple code fix, we have control over that.

Phil Archer: Great, then let’s get that fixed.
… Joe and I have a list of things to finish up –
… Issue 13 describe relationship between DID Methods and DID Authentication in Use Cases document (raised by Mike)

Ivan Herman: https://github.com/w3c/did-use-cases/issues/13

Joe Andrieu: We have some authn use cases, we didn’t want to specify solution-based documentation, we might not want to talk about this.

Phil Archer: Do we need time on this?

Joe Andrieu: I’d like to just close this - authentication is intended to be method independent, I don’t know how we describe relationship other than that, current language doesn’t confuse the issue on that.

Daniel Burnett: Sounds like a direct email to Mike would be good

Phil Archer: Then let’s note this as pending close.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/52

Joe Andrieu: Issue 52 Consider use cases from key representation discussion in did-core

Ivan Herman: https://github.com/w3c/did-use-cases/issues/81

Phil Archer: Issue 58 Suggestion: Better partitioning of “DID” actions Text already updated. Need to create better diagram, likely to be a set of SVG diagrams.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/58

Phil Archer: I need to create a set of SVG diagrams to make explicit what actions are.

Ivan Herman: https://github.com/w3c/did-use-cases/issues/62

Phil Archer: Issue 62 Jargon from VCDM and crypto. Need to read through and generally make it more readable. Lots done in this regard but more to do.
… WG Member’s to do list – If your use case isn’t there, or if your requirement is not covered by a use case, Please supply a PR… focus on DIDs, NOT VCs.
… We have a PR outstanding but the contributor, YueJing95, has not responded to request for clarification.

Ivan Herman: See outstanding PR

Phil Archer: Re-do collation of requirements (including issue 87 domain map)…
… We won’t rename the master branch…

Daniel Burnett: Thank you, fabulous - increasingly in good shape w/ that document - please do continue to contribute. We have 15 minutes until break.
… We don’t have a lot of time in this meeting… surprise request of Orie – since we didn’t put anything about Registries – is there anything you’d like to get group input on?

2. group input on registries

Orie Steele: I think it’s ok to not have any registries issues discussion… we are going to talk a bit about this in key representations… ethereumAddress support.
… I’m advocating strongly for it’s support in DID Core JSON-LD context… I think if people are looking for issues, PRs to review - please see DID spec registries.

Orie Steele: https://github.com/w3c/did-spec-registries/pull/73

Daniel Burnett: I’ll take you comment, Oliver, but may want to discuss later.

Oliver Terbu: Recently we opened issue on registry for transform-keys=jwks - right time to discuss this?
… Wanted to say that this is a feature that’s very useful – DID SIOP spec would strongly benefit from that feature… don’t know if this is the right time, or can jump into that later?

Dmitri Zagidulin: link to that issue?

Daniel Burnett: Orie, thoughts?

Dmitri Zagidulin: about transform-keys?

Orie Steele: We could cover it as it relates to key representations… could be DID Parameter that added that to DID Registry, we have seen enough examples of it, detailed enough about that.

Daniel Burnett: When we’re talking later, we’ll bring it up.
… In interest of best making use of F2F time – suggestion brent?

Brent Zundel: One thing we need to do is get scribe after break… other than that, happy to chat.

Ivan Herman: Echidna isn’t working on DID spec registries…
… Editors should look at what is happening… if there is a problem, I can talk w/ deniak.

Manu Sporny: The Editors will take a look.

Daniel Burnett: Anything else from anyone else for now?

Brent Zundel: +1

Eugeniu Rusu: +1

Daniel Burnett: We’ll take our break now, start 30 minutes from now.
… We will start at 11:50am.

Brent Zundel: We’ve established two different zoom rooms for that use.
… One issue is you don’t know who is in a room before stepping into it.
… Breakouts are on slide 3

3. DID Rubric

See slides

Daniel Burnett: the main question is whether we still want to do a decentralized characteristics rubric?

Jonathan Holt: -1 too early

Dmitri Zagidulin: +0

Daniel Burnett: +1 we do, -1 we don’t need to

Oliver Terbu: +0

Ivan Herman: +1

Justin Richer: +0

Adrian Gropper: +0

Eugeniu Rusu: +0

Charles Cunningham: +0

Manu Sporny: +0 – don’t know who in the industry needs it.

Brent Zundel: -0

Christopher Allen: +1

Amy Guy: +1 because I thought we had started and it seems quite important but I might be missing something

Christopher Allen: But not strongly

Daniel Burnett: nothing has started in the WG yet, there’s no rubric document yet
… we’re going to discuss here

Manu Sporny: it may be people are on the fence because they feel like they don’t need it, things have been resolved
… the rubric came up at a point where we were really wringing our hands around centralized vs decentralized DID methods
… another thing to think about is that if we don’t do a rubric of some kind another organisation is going to do it and we will probably have no power in influencing that discussion in the worst case
… by choosing not to do this we should realise that somebody else is going to pick it up

Brent Zundel: The rubric was recommended as a way to address the challenge of calling our identifiers “decentralized”

Daniel Burnett: we’re going to go into discussion in a moment
… for people who joined us late, we’re not explicitly discussing not doing the rubric, I wanted to get a sense from the group of how much interest there was in doing it
… let’s have a bit of discussion
… I’ll leave time for us to discuss what might be a starting point, assuming there is someone interested in doing it

Adrian Gropper: people are going to attack us whatever we do from the unintended consequences of privacy aspect. I don’t think a rubric document is the way to solve that
… we’re not dealing with the unintended consequences of the core spec

Ivan Herman: i think the group has to produce documents that are not for ourselves, our implementers etc
… to people around us for whom DID still remains a somewhat difficult to understand spec
… we will need this kind of document
… one of the issues that will come up is you guys produce loads of methods why should I use this one or that one
… what’s the reason and whatever, I think the goal of the document is partially to answer these kinds of questions, which are already there

Wayne Chang: the concerns just now, picking the right did method and privacy concerns, these are some important dimensions of value i’m seeing out of a rubric
… specifically decentralisation
… if you’re trying to have censorhsip resistance. how resilient is this actually? some blockchains are just run on three nodes
… these measures, the single measure across many blockchains, how expensive is it to start adjusting your DIDs
… having objecting tests that can measure these metrics we can all agree on would be hugely useful, in terms of picking the right DID method to a use case
… +1 to the privacy aspects, there could be implications if you had a more private use case

Drummond Reed: one of the most valuable aspects is education about what decentralisation means
… there are a lot of folks, that’s a new concept
… why is decentralisation important?
… this document a little bit indirectly has a lot of education about that
… i agree with ivan that it’s the kind of document you would expect a mature spec like this
… it will be referenced a lot
… as we discussed when we created it, we couldn’t find a reference for that definition
… a lot of work has gone into it

Daniel Burnett: no work has gone into it from a WG standpoint

Brent Zundel: could some of the original intentions of the rubric be met by the implementation guide?

Jonathan Holt: certainly this topic has come up in a CG, I think it was incubated too early and we are a biased bunch
… i welcome an outside objective view on this

Kaliya Young: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu

Jonathan Holt: I see this as a method of weeding out different methods
… if we more formally define what decentralized, portable nature of it and hand that off to an outside group to give us an outside perspective

Daniel Burnett: for this document we do not have to all agree that it needs to be done
… we just need to not have anyone who objects
… my secret reason for asking is because assuming there’s enough support for doing it is I expect the people who spoke in favour to do the work

Oliver Terbu: as one of the contributors to the rubric do, I believe it’s useful as it has education in it, but as it is currently written i feel like certain types of methods might be discouraged
… to my surprise, not necessarily those who are supposed to be.. the ones more decentralised.. I’m generally okay with having it, but if we do so i suggest we don’t include a full evaluation of each did method
… the evaluation is always very subjective

Chris Winczewski: +1 oliver

Drummond Reed: +1 to not include an evaluation, other than some simple examples

Oliver Terbu: we might even ask the method authors if they feel okay with the current evaluation

Orie Steele: i’m one of the authors of one of those PII DID methods. It’s very helpful to have DID methods that have certain characteristics that we might consider to be ‘bad’ from a privacy perspective, but might be good from a public reputation perspect
… it helps provide clarity on the advantages of all the other DID methods
… I’m a big fan of having the rubric and committing the work to describing the differences between these things

Christopher Allen: i have mixed feelings

Drummond Reed: +1 to Orie’s point about using the Rubric to describe many different kinds of DID methods

Christopher Allen: I like the work that was done in the CCG and elsewhere
… IIW and RWOT on the rubric
… but there have been several people already on this call that have said oh it’d be useful to help choose between methods or to filter methods or to eliminate methods
… and that i think is exactly part of the problem
… the intent, especially moving to the language of rubric, wasn’t that we would make any decisions about that type of stuff
… it was up to the implementers
… i’m concerned about it
… my question is is there a substitute now that we’ve gone through the exercise of their rubric to take what we learned and do a note on decentralisation, not on how to evaluate methods?
… i’m kind of leaning in that direction rather than the rubric as much as i like the rubric

Joe Andrieu: some people may not know we’re basically done with the rebooting paper
… amy has volunteered to help us turn that into respec
… we’re going to have a proposal for consideration
… i want to touch on some of the challenges we had, they have not gone away
… i second oliver’s observation. we have to provide examples, it was almost impossible among the authors to really understand some of the descriptions without concrete examples, but we shouldn’t use all methods across all examples
… the fundamental problems were about, 1 it is not the kind of thing that has been asked for from wayne, it does not address privacy and security
… it’s only decentralisation

Orie Steele: centralization => less privacy :)

Joe Andrieu: lots of people want to use it to evaluate which method, but the current work doesn’t really address all of that
… it’s going to be hard to figure out how we deal with the boundary of what’s decentralization and not
… given that balance, i think we should do something, but still a lot of work

Orie Steele: single point of correlation.

Dmitri Zagidulin: before when the did methods registry still belonged to the CCG i would have said this is a document to help people make sense of the did method registry. I agree with ivan, we have produced too many and we’re confused about which ones do what
… now that the responsibility for did registries is passed to the WG we should probably do this document here
… because if we don’t we will have failed in marketing and publicising DIDs if people see 60+ methods
… Also, what if we explicitly put the differing opinions illustratively into the rubric? to help people.. it’s like when you’re reading product reviews, you look for 5* and 0* to help understand both sides

Daniel Burnett: what i heard as chair is sufficient interest in creating a document
… it may be the rubric or a successor
… we are not required to state in advance exactly what a note must be, we can publish a note on anything we wish at any time
… i’ve heard enough support for creating a document, the contents people disagree, that’s fine, we can work on that
… i’m going to declare enough interest in creaing something, people willing to work on it
… the next question - what should we use as a starting point for the document
… and i’d like to give JoeAndrieu first opportunity

Kaliya Young: yes we should have a document - specifically because of the concerns raised by the privacy community.

Orie Steele: See https://github.com/w3c/did-rubric/issues/2

Joe Andrieu: we do have a document

Joe Andrieu: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu

Joe Andrieu: this was a rebooting paper, 6 or so of us worked on it for the last year
… it was a lot of work
… it still has rough edges
… part of the problem is in order to evaluate any methods you have to note things about the method that are not well documented because there are questions about governance
… you may need to know internals of the organisation that created the spec which may be hard to find
… that said, it’s an interesting starting point because it has been kicked around
… it’s not a gold standard
… it has a certain maturity that would be nice to leverage
… what we do need is someone else who can work with some of the continuing authors who might continue (I will) but we need someone who can break out of the mould we set with that
… it needs to be broken and fixed in a constructive way
… resetting a bone..

Daniel Burnett: we can discuss some more
… what i’m looking for is people who might have a concern or wants to discuss before we do a proposal
… just a straw poll

Jonathan Holt: it’s just so hard, i’ve seen this before, it’s huge to consume, i’d like to ponder it
… but it seems very much like a filtering mechanism that i’m not too fond of

Christopher Allen: But is it to be a rubric?

Jonathan Holt: but it has some good fodder for discussion about defining more material for us to pass on
… to external groups to educate them about the criteria

Daniel Burnett: we’re looking for a starting point, not approval.. it could be one word that says ‘document’

Brent Zundel: to extend the bone setting metaphor.. when a doctor sets a bone he knows approximately what shape the arm should be
… do we have some sort of idea what shape the final doc ought to be?
… that’s the hold up for me personally
… i agree there’s a lot of great information in the rubric and a lot of work has gone into making it, it could be a great starting point
… but do those who want to continue have some idea of where they want to go with it

Daniel Burnett: this should be open discussion now, 17 minutes left, will be looking for resolution
… the goal now is to see whether we can get to a starting point

Adrian Gropper: i’m pondering on joe’s point about the governance issues
… i think, i am willing to help work on this doc, i think it’s value will be to the extent that it does highlight or educate about the governance of different methods
… if the main reason is to help people navigate through the 60 methods, i would say that governance is one of the most important things that would have to deal with

Joe Andrieu: i’d like to put before the group as we choose how to move forward, responding to brent, do we know what the document shape should be - seems there’s an important choice and we need to make it as we come into this work
… is it going to be just decentralisation as the current rubric is? or do we want to include sections for security and privacy and have it be a rubric for the evaluation of DID methods
… broader, more work, but it seems like what people are asking for
… quite a different shape if we add security and privacy

Daniel Burnett: i don’t care which direction we go. my only concern is i’ve seen group want to agree on all of the details before they begin

Orie Steele: +1 to burn…. we need to agree to do the work and put people in charge of moving stuff forward… not solve the problem today.

Daniel Burnett: … will be looking for.

Manu Sporny: at this point we have a document that has been worked on for a year on and off and what i see as a very good starting point fo ra variety of the things we’ve discussed
… that’s option 1
… option 2 is let’s just not do the work
… enough people want to see something happen here that let’s not do the work would probably result in people objecting

Brent Zundel: that matches my understanding of the options as well

Manu Sporny: it really feels like we have one workable option
… someone can always propose they’re going to go off this week and write something but i struggle to see how it would have the amount of thought and content
… so +1 to take the work already done and transition that into the first editors draft
… as far as a starting point, I don’t see any other workable option
… the second thing, it feels like what the document is today and what people are asking for are fairly different
… i think there’s enough raw content in the document we have to get to what folks are asking for but it really seems like.. we’ve heard a number of people say i would like something that will help me pick a did method
… i think the document as it stands today is more a list of questions you should ask yourself
… it may not give you the type of clarity that people want
… having been involved in writing these flow charts to help people pick something, usually want people want is a nice guided tour of 60 options and when they get to the end of the flowchart tour, do you want this or that, is this or that important, you whittle down from 60 choices to 3
… fundamentally that’s what people really want
… they don’t want to read a giant document
… the actual desired work item is a help me pick a did method work item
… not these are all the ways things could be viewed as decentralised or not

Ivan Herman: my answer is yes, whether security and privacy should be addressed
… as far as i can see, of course decentralisation is a central feature, but so is security and privacy

Orie Steele: can we interpret +1 as start with the doc, and -1 as lets not do the work?

Chris Winczewski: i would support using this doc as a starting point
… and the expansion as ivan said

Drummond Reed: +1 to starting with this submission and +1 to adding discussion of privacy and security

Oliver Terbu: +1 using the rubrics doc as a starting point

Chris Winczewski: i do think our role in this, all of us are way too close to this. what we should be doing is explaining how did methods work from a technical standpoint so third parties can evaluate what works for them

Brent Zundel: +1

Chris Winczewski: i don’t think we should be enabling evaluations

Proposed resolution: Use https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu as a starting point for a document intended to become a WG NOTE. (Daniel Burnett)

Manu Sporny: +1

Orie Steele: +1

Ivan Herman: +1

Drummond Reed: +1

Kyle Den Hartog: +1

Joe Andrieu: +1

Wayne Chang: +1

Christopher Allen: +1

Adrian Gropper: +1

Markus Sabadello: +1

Kaliya Young: +1

Daniel Burnett: 0 won’t have an effect, -1 means we won’t use this a starting point

Eugeniu Rusu: +1

Chris Winczewski: +1

Amy Guy: +1

Oliver Terbu: +1

Jonathan Holt: 0 my concern that the true meaning of Rubric is “A statement of purpose or function” as in how a church service should be conducted. but the direction here is a set of criteria to judge that church service

Daniel Burnett: i’m going to call it

Resolution #2: Use https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu as a starting point for a document intended to become a WG NOTE.

Daniel Burnett: marking resolved, the did spec we have today is definitely not the same as what we started with
… the work can begin
… joe, the chairs would like to talk with you about how to get started

Christopher Allen: Add me.

Orie Steele: can I nominate daniel buchner from ms?

Daniel Burnett: if there’s someone else who is willing to commit a lot of time on this as a potential editor, please drop your name in irc or contact us directly and we’ll get that started

Adrian Gropper: agropper willing to edit

4. implementation guide

See slides

Drummond Reed: another one of our deliverables
… markus and i were trying to figure out, we couldn’t remember when we decided to add it and does anyone remember when we made the decision to do this?

Markus Sabadello: i remembered it, we created the implementation guide repo about 2 weeks after the Amsterdam f2f because during that meeting we had lots of discussions about topics that don’t fit into the core spec
… topics around immutability of objects, identifiers for keys, things like that

Drummond Reed: more recently as we were crafting and taking early parts of the did spec from the CCG, there were certain sections where we said that won’t belong in a final w3c spec like the future work section, so we moved that to the implementation guide
… manu did that
… we definitely do feel that it is a good place for best practices
… at least, whatever our learnings are at the time we are done with did core and the registries
… so we just listed a set of bullets
… some very specific advice that we want to be able to provide to did method spec authors who are direct audience of the did spec
… and implementers of resolvers, to extend verifiable data registries. should not touch on the rubric except to point to that. and application developers, general use of dids
… that’s what we felt it’s for
… we still have a fair number of questions about what else might go in there
… we thought we’d start by sharing what’s in there now

Markus Sabadello: over time there have been many ideas and comments on gh issues and PRs to discuss or suggest what kind of topics could go into it
… quite a few issues on the did core spec where the implementation guide has been mentioned as a potential place for certain issues to be addressed
… in practice we don’t have much
… two topics that manu moved from the did core spec to the implementation guide
… some content about the use of jsonld
… the implementation guide talks about some specific jsonld features, jsonld 1.1 features, how to use them, what to watch out for as an implementer, how to extend it and use contexts etc
… the second item is the future work section which used to be in did core
… things like equivalence, or use of vcs, did doc recovery
… one thing i did was search the issues and prs on did core spec where implementation guide had been suggested
… it has been a frequent pattern
… we discuss topics and there may be an insight that the topic should not result in content for the core spec but is more suitable for the implementation guide
… about ten issues
… just a plain text search
… here’s one example
… a few months ago an issue was raised on the core spec to suggest we discuss the relationship between DIDs and eIDAS, an EU framework for traditional state issued identity infrastructure
… some ongoing efforts and initiatives to align with DIDs
… someone raised an issue suggesting we should cover that topic
… i think in the course of the discussion we had a better understanding of what type of content should go into which document
… my feeling was the did core spec would not be a place where we discuss identity frameworks, and there are many, how dids would be implemented and aligned with some of these
… not for the core spec, but something that could fit into the implementation guide, and also the use cases or to a smaller degree into the did core spec
… there is a proposal how this very broad topic could be split up
… there could be some small improvements or updates to DID core
… the main content to address this would go into use cases to describe what is it for
… and why are some politicians working on that
… and then the implementation guide would be a place for describing how that is done on the technical level
… there are some concrete implementations or gateway initiatives, actual code has been written to align dids with this identity framework so i think this would be a good thing for the implementation guide
… this is just one example

Drummond Reed: we want this to be a question to discuss - what other types of content seem like they could be good candidates
… the topic of all the ways you can use, good guidance to provide around dids and did docs could be very broad
… all the questions around how they relate to decentralised pki relates to convential pki
… very deep topic around proof of control
… security of dids

Markus Sabadello: a topic daniel hardman suggested
… service endpoints and verification methods inside the did doc, many discussions on how these ids are generated or designed and should be immutable or not
… when you change your key, update it in the did doc, you rotate it, does the new key still have the same id value as the old key? or does it change every time you change the key?
… at some point we said the did core spec would not mandate how you generate those ids, but there are good practices and security considereation, could also be one topic, identifiers of keys and other things inside the did doc

Drummond Reed: some of these you can look at like whole docs or notes themselves about them
… for shorter things we could have a section of the doc that is an faq, there are a lot of common questions about dids
… eidas is a subset of the question of dids and how they relate to national id programs, that’s a topic i’m talking about every day
… another area that has a lot of attention is activitypub, federated social web and all that
… a lot we could cover
… part of what we should get feedback on is what is most appropriate and what is highest priority
… and an open question about timing
… volunteers for editors? and encourage PRs
… main question is to ask for feedback about what folks feel should be the main thrust of the guide if there is one
… and ideas for content people have

Jonathan Holt: cbor is missing, i’d be happy to contribute, now i really understand cbor and cddl and have working code to do it i should contribute

Drummond Reed: fabulous
… it would fit right alongside the section on jsonld
… maybe if the plain json folks it would be good to have a subsection of the document about specific representations

Kyle Den Hartog: one thing i’ve noticed tribal knowledge about the relationships between controllers, subjects and delegates. a lot of nuance and edge cases around that we can’t really put in the core spec
… curious if this is the right place to do that

Drummond Reed: that’s another great topic
… the core definitions need to be in the core spec, but some of the more advanced questions about how those things might be put together belong here

Ivan Herman: you had a slide on the relationship with eidas, triggered a more general thing
… maybe worth creating bridges with the uses cases
… use cases with implementation may not be that obvious. in the implementation guide give examples of the most important use cases, a realisation of how that use case can be done by this and this type of DIDs

Drummond Reed: great idea

Manu Sporny: to speak to the question around priorities
… i wanted to draw attention to something dmitri said in chat, which was great
… half joking.. which is talking people out of doing things in the implementation guide, if you are seriously considering doing a did method please take a look at the ones that exist already
… another one might be if you’re thinking of creating new types of crypto suites, really understand why you’re doing it
… because the world may not need yet another one

Ivan Herman: +1 to manu’s comments

Manu Sporny: it’s general guidance on please don’t do these things that are harmful to the community, well intentioned but harmful
… and having a section on specifically not doing things, avoid doing these things, would be useful

Drummond Reed: I strongly agree with Manu’s points – the “PLEASE DON’T DO” section

Drummond Reed: i agree so much

Markus Sabadello: i had the same thought as ivan, there could be a relationship between the use cases and this one

Drummond Reed: +1 to “antipatterns”

Markus Sabadello: ideally we have someone contributing the use case and how they implemented it

Drummond Reed: this is perfect, the implementation guide is now a book published by o’reilly…

Manu Sporny: yes!

Kyle Den Hartog: is this a place to talk about how to define an extension?

Drummond Reed: what a great question

Manu Sporny: great question, kdenhartog

Orie Steele: …. :(

Drummond Reed: my reaction, better in the did registries, but i’m curious

Orie Steele: +1 to drummond… lets centralize extensions in 1 place

Orie Steele: i would prefer to put as much guidance on extensions in one doc as possible and link to that single place
… from any docs that might have related topics

Drummond Reed: certainly that we would want to point out the general need or pattern of use of spec registries for extensions, go look there for instructions

Orie Steele: yeah, here’s the spec registries, here are properties in the core context, here are properties defined elsewhere, in the implementation guide if you believe you need to extend the core data model go over here to the registries and if you want your extension to be interoperable you’ll have to conform to the mechanism

Drummond Reed: actual instructions on how to register an extension, in the spec registries document?

Orie Steele: if there is not a section that explains how to do that, it’s almost useless

Kyle Den Hartog: thanks makes sense to me

Manu Sporny: just to clarify orie, i wa snot entirely clear on what you were suggesting. i think there’s a nuance that kyle might be getting at
… adding something to the registry is one thing, creating an extension is something else
… instructions for adding should clearly be in the registries. the process a developer would og through to create an extension might be better placed in the implementation guide
… it could also go in the spec registries document.. but that would be a fairly nonstandard way to do this..
… typically spec registries don’t have instructions on how you write extensions
… the question is the process of creating an extension, do we document it in core, implementation guide or spec registries

Daniel Burnett: +1 to extension process in core for core registries

Orie Steele: +1 to did core

Daniel Burnett: i’m going to speak to that to say if you look at ietf docs, yeah your spec needs to define the process for registering new entries
… for the core spec
… where it gets interesting is we’ve combined a variety of things into this did registries
… there may be some things that are not really defined by the core spec that maybe belong somewhere else, but normally you put it in your normative document

Justin Richer: +1 for process in normative document, IETF requires “IANA Considerations” sections

Daniel Burnett: any other comments?
… what i want now is people to commit to editing this document
… contributing this document
… so we can get it done

Drummond Reed: as folks contemplate that.. in terms of timing.. would it be safe to assume that the priorit should be for folks who do want to contribute
… feature freeze on did core?

Daniel Burnett: yes

Orie Steele: ^ yes, to be clear… I would prefer the process of defining extensions in the normative document…. agree strongly with justin.

Manu Sporny: yes, please, feature freeze on DID Core is Priority #1 :)

Drummond Reed: let’s make sure we get did core done and any essential things there or in registries, then a lot more of us as that happens will be able to start fleshing this out
… another question, a document like this, what is the actual status of an implementation guide?

Daniel Burnett: it’s a note
… . there will not be normative language. you can write whatever you want
… the entire doc is informative

Drummond Reed: when should we be really saying we need to have it really ready for final proofing

Daniel Burnett: the answer i’m going to give is i suspect as we require and encourage more reviews of our core spec we are going to get questions for whom the answers are in the implementation guide, or should be
… it’s tempting to wait until the end
… but if it ends up being a blocker for getting our review work done on the spec we need to put earlier effort into it
… otherwise the only deadline for it is the WG’s completion in september of next year
… we need implementations, that’s part of the process
… if your’e hoping people will look at the implementation guide when they are building, it’s good to have something there
… in the VC case, we had concerns people raised they wanted to make sure they were written somewhere, they were not comfortable with the spec being done without text in the guide
… even though it’s not normative, the group members wanted to see it before they would say yes to the spec
… that’s why i’m going to encourage this work to get going after feature freeze
… don’t wait
… the next step after feature fereze is CR, which means implementations

Brent Zundel: +1 to not waiting

Daniel Burnett: the implementation guide will be relevant to that i hope

Drummond Reed: makes sense
… everything we put in to guide implementations during CR, and the revisions we make after we learned that much more from the implementations

Daniel Burnett: sure
… anything else on this?
… thanks drummond and markus for putting this together

5. features at risk, CBOR and JSON

See slides

Manu Sporny: let’s start off by talking about what they are
… for some of the people in this group, it might be your first time through, so we’ll establish what a feature at risk is
… we usually start talking about it when we get close to candidate rec phase
… the main reason we do this is as dan mentioned if we change anything substantial in the CR phase, if we change normative statements that affect an implementation, if we add normative text, if we make any change that changes an implementation we may have to go through another CR publication process, it takes time
… it’s expensive when we’re in CR
… what most groups try to do is protect themselves when they go through CR
… the main tool they use to do this is ‘feature at risk’
… this is a provision the w3c process provides when you mark something as a feature at risk, you’re signalling to implementers
… that this thing could change, keep your eye on it, we may change it in a significant way or remove it completely
… by marking at as such then you don’t have to go through a new CR phase if you end up changing that feature
… you can abuse this and mark the entire spec as at risk, clearly you have to be very precise on the sections or features you are marking as at risk
… so it’s something you expect is going to change and you don’t want to that to affect your ability to go to PR
… any questions?

Christopher Allen: do we need to register tags at ietf because they’re the org that registers cbor tags?

Manu Sporny: good question
… cbor is a topic of discussion in this hour, we’ll cover it later
… a fundamental things we have to figure out

Christopher Allen: (I’ve been puzzling through CBOR crypto tags at https://github.com/BlockchainCommons/Research))

Manu Sporny: there are a variety of reasons why you’d want to mark something as at risk
… if you think a feature will get less than two implementations you should mark it at risk
… if you expect there to be a normative change
… there’s a table of normative values that may change based on implementation experience
… if there is a feature that you feel is not thoroughly documented. we don’t like to go into CR with features that still need work or are not thoroughly documented
… but sometimes groups do this, especially for rough features that appear a couple of weeks before CR
… usually you want to mark those as at risk because the group doesn’t have enough experience to know whether it’s going to change
… the other thing that may trigger it is you’ve got multiple people implementing things
… you’re getting signals that there’s not actual interop
… you have to be careful about even if you have independent implementations you have to look to see if things are shaky
… there are also looming formal objections, if you get one during CR marking something as at risk allows you to remove the feature to address the objection
… or feelings that a section isn’t great, or this section is giving me heartburn… usually not a good reason, but it’s very much a judgement call
… the group needs to figure out which items to mark as at risk before we go into CR
… there are around 5 areas of at risk concerns in the spec today
… i’m going to go through them and introduce them, and then talk about ways we could mitigate these at risk concerns

Daniel Burnett: in your position as editor that you believe that as these items currently are they would need to be marked as at risk if they remain the way they are today?

Manu Sporny: that is correct
… not representing anything other than editor of the spec
… So, there was quite a bit of work on json only did docs
… concern around ensuring the jsonld community as not pushing jsonld things onto the json only community
… there has to be a representation of a did doc that does not require jsonld
… we’ll get into why this may be at risk, but at present we don’t know of two independent implementations of DID methods that are json only
… meaning they don’t use any of the jsonld stuff
… that coupled with the lack of contributions to the did spec registries for the json schema work
… and other items like that
… have raised concerns around which organisations are going to produce a json only representation
… it’s not we’re thinking of doing it, or we will if we have time, it’s this is the main mode of operation for our did method and we will be providing something during CR - looking for a signal like that and haven’t seen something like that yet
… still plenty of time, but if we don’t see something like that soon we may have to mark the json only stuff as at risk
… the same thing applies to CBOR only did docs
… at present we only know of one implementer one implementation
… the text is a bit rough
… it does point to ipfs style things
… but there are also concerns around that second implementation
… no additions to the test suite, to the did spec registries
… there’s a significant amount of work that would need to be done for us to keep the cbor only bit in the spec
… i forgot to mention for json only, we’re also looking for people to submit json only tests to the test suite
… you need to run the tests to do the json only stuff, we need someone to step up and write those tests as well
… oliver mentioned a couple of items and adrian - the concept of gdpr and other privacy implications on services exposed via the services parameter
… question on whether services are a good idea from a privacy perspective or if we should figure out a different way

Justin Richer: about the test suite and counting implementations, towards the tail-end of finalising VCs tests was counted as one of the implementations to remove things from being as at risk
… will that happen here as well or are we looking to avoid that?

Markus Sabadello: i think that services topic is not so recent, it’s come up several times in the past
… that the did doc should not contain services has come up

Kyle Den Hartog: if we did remove it is it possible it could be defined as an extension?

Manu Sporny: short answer yes
… justin, i can’t remember us counting the test suite as an implementation in the vc work

Justin Richer: we did count it for several things, that wasn’t part of the question but ok

Manu Sporny: i think they were all independent implementations. i don’t think we did that there
… we’ll have to consider that here

Adrian Gropper: The Services topic was being discussed in Hallway at the last break and maybe can continue tomorrow.

Brent Zundel: to my recollection, we did not include the test suite as an implementation in the VCWG

Justin Richer: manu no I am not asking on anything in particular, please don’t speculate

Manu Sporny: i think you may be asking around the resolution stuff, i think there’s a clear path forward meaning we wouldn’t have to count that stuff as an implementation for it to stick
… the VC test suite did not count itself as an implementation, we used other implementations

Daniel Burnett: that would be a no-no for that officially to happen

Oliver Terbu: if did-method critical features are not getting into core context easily, there would be less concerns with keeping it jsonld only

Orie Steele: +1 to what oliver is saying…

Oliver Terbu: if json gets dropped and things like ethereumAddress are not added I’d consider formal objection to the spec

Jonathan Holt: i haven’t seen any feedback or issues filed or prs against it or comments, i have been waiting to have dialogue, maybe we can have some time to discuss that

Christopher Allen: post the PR url?

Jonathan Holt: it was just submitted a few weeks ago, i spent a lot of time on it, but it’s brewing form a year and a half ago
… i think it’s relatively solid
… to comment as far as implementations, underlying the implementation of cbor i’m most familiar with is dag cbor which ipfs uses
… there are other implementers who use this particular method, ipid, in one line to publish the did doc into cbor
… i can document those libraries
… and how to do that
… chicken and egg
… you have to have two separate implementation, or two to use your did method?

Brent Zundel: two different implementers who use CBOR

Christopher Allen: i’m confused on a couple of different areas
… when people use cbor that is straight conformant in the ietf but not the ?? specification for the DID doc
… 3 parts to my question:
… 1. the relationship with other organizations (having to register with IETF)
… 2. what is the relationship with how much we have to do with a method, vs. what needs to be done in the DID spec
… for example, if i can take any conformant JSON-LD doc and convert it to CBOR, do i even care if the DID spec allows for CBOR?
… 3. did we say we may have to conform with protocols labs things? they are neither a standards organization nor a standards implementation organization

Kyle Den Hartog: The simple way to address this may be to ignore.. Let’s say JSON and CBOR are both dropped, and we only have JSON-LD, does this mean we go back to only a single concrete representation?

Christopher Allen: To be clear, my use cases use QR codes, that is one of the reasons why use use CBOR. See https://github.com/BlockchainCommons/Research

Kyle Den Hartog: or… even if the features get dropped, do we still stick with the abstract representation?

Manu Sporny: i wanted to address the meta-concerns i am hearing. as an editor, i think it would be a very bad idea to drop JSON and CBOR

Orie Steele: well… JSON-LD is JSON… its a stricter subset of JSON…. and to answer kyle’s question… yes, you could create a bi-directional map[ing between JSON-LD and CBOR / JSON on your own….

Drummond Reed: +1

Daniel Burnett: +1 to doing work. manu is pointing out that the answer cannot be “someone (else) needs to do something”

Jonathan Holt: brent: two different did methods that use CBOR?

Manu Sporny: but the reason why we are highlighting these things.. we are saying that unless people step forward and do the work to demonstrate interoperability between implementations, we are not going to be able to keep the features int he spec
… this is about people stepping forward doing the work, this is not one sub community attacking another sub community
… we are saying, we really need help, especially from the people who want to see the features, so we are able to safely defend the features
… so my hope is that dropping features is hypothetical
… the JSON one feels easier than the CBOR one
… i don’t think this is realistic, but if JSON and CBOR are removed, my expectation is that the abstract representation will remain as it is

Ivan Herman: +1 to manu on keeping the door open in any case

Manu Sporny: we always want to keep the door open for future additional representations

Markus Sabadello: +1 to keeping the door open

Drummond Reed: +1

Manu Sporny: i think it would be very disruptive if we removed the ability to add representations

Kyle Den Hartog: +1 for keeping door open

Orie Steele: +1 to keeping the door open…

Daniel Burnett: there is no decision to make here, manu just pointed out the situation

Drummond Reed: i wanted to second what manu said. i know that there is work ongoing.
… i’ve heard several times the notion that there is not a DID method that supports that
… representations are completely orthogonal to DID methods
… a DID method that only works with one representation would be an anti-pattern
… you may present examples using one type, but methods should not be limited to one representation

Ivan Herman: i agree with drummond. the “JSON only” and “CBOR only” terminology is misleading
… if we have DID methods supporting multiple representations, we will be fine
… the requirement is that DID document e.g. in CBOR are interchangeable among implementations

Orie Steele: did methods need to support representations, in order for them to be testable… you can’t test normative statements about a representation that has no method implementations!

Kyle Den Hartog: realistically, we don’t want that to happen. the way we have implemented it is that we use JSON-LD, but we don’t use JSON-LD tooling. we do it with standard JSON processing (we’re using typescript)

Orie Steele: +1 to kyles point… we also use JSON-LD and TypeScript…

Kyle Den Hartog: it feels weird to say “JSON only” because we’re processing JSON-LD with standard JSON tools

Kyle Den Hartog: I can take that conversation offline as well to figure that out

Jonathan Holt: my DID method IPID supports DAG CBOR natively but it can be serialized to JSON
… it supports CBOR LD too
… if i were to have a second implementation, e.g. i fork indy and i add CBOR, is that sufficient?

Manu Sporny: no, because it has to be independent

Christopher Allen: when i heard “CBOR only”, i thought it was a “linked-data-less” version
… which of that are we proposing to do

Ivan Herman: we do not have CBOR-LD ad the moment, ChristopherA

Manu Sporny: possible mitigations:
… if we are concerned about JSON-only DID document, we need to see two independent implementations
… same for CBOR
… for the services topic, we can mark as risk

Orie Steele: For those wondering what “Linked Data” is, and why you might want your did document to be represented as linked data: https://en.wikipedia.org/wiki/Linked_data

Manu Sporny: for the publicKey topic, we seem to have agreement to replace that with “verificationMethod”
… if we missed anything, please type it here in IRC
… also, please think of missing features

Kyle Den Hartog: For safety the sections I just added may be useful to mark “at risk”

Daniel Burnett: tomorrow’s call begins two hours later than this one

Brent Zundel: thanks to the scribes, thanks everyone for coming and making this a priority

Daniel Burnett: we will continue tomorrow. bye.

6. Resolutions