– DRAFT –
Decentralized Identifier Working Group

Volunteers for Horizontal Review Documents

manu: Every document we publish on standards track requires horizontal review
… This means we talk to W3C groups like technical architecture, internationalization etc to make sure our specs meet their guidlines
… We are also supposed to engage with people in our liason section in our charter
… It is best to start horizontal review as early in our process as possible
… There is a significant amount of work we have to do as part of this process
… Each group has a slightly different way to do this
… e.g. for the technical architecture group we need a one pager. Others require us to perform a self review
… What we need from the group are volunteers to help us do these self reviews etc
… For documents we have done in the past we have previous documents we can iterate on
… The DID spec is largely the same just a 1.1. rev
… For DID resolution, this is a new spec. We will need a new document.
… This usually falls onto the editors, but it is a lot of work. It would be great to have volunteers.
… The more we have, the faster this will go
… There are web pages that show what each group requires
… This is something that anyone in the group can do. No deep knowledge of process required

manu: This is a 1-3 hour amount of work

<ottomorac> ack: ivan

ivan: In other working groups it has paid off already to have people volunteer to be continuously watchful of specific areas, e.g. internationalization
… The can be watchful of issues with this area in mind
… If there are questions for this group, they can manage the coordination

<ottomorac> Example of previous horizontal review for DID, for example: w3c/did#292

ivan: This makes the end formal reviews simpler and easier

<ottomorac> Documentation on how to get horizontal review: https://www.w3.org/guide/documentreview/

ivan: In this group accessibility is not really central. Internationalization maybe. Security and privacy definitely

<ottomorac> ack: wip

wip: I think that sounds great. I wonder what is the next step to make this happen. Do we create issues? We need to identify all the groups and get volunteers.

manu: I think the best thing to do is open an issue on all the specs we want horizontal review on
… In that issue we can assign volunteers, each person comment as to what group they want to take on
… Eventually we will open an issue on the respective groups tracker asking for a review

<Wip> +1 that sounds good to me

ivan: We have labels in the repositories that are automatically added in the W3C repositories.
… Important to use these, as they flag issues for the respective groups to review
… These are all details, we need to figure out

<manu> +1

<swcurran> +1

<KevinDean> wip: When we do proposals, it's good to do the /me command.

<KevinDean> ...Manu, you don't think we need a proposal.

manu: Raising an issue now and will add it to the minutes

<manu> Here is the Horizontal Review issue for DID v1.1: w3c/did#885

manu: Markus if you can raise a similar one for DID resolution

manu: Asking for volunteers please

<ottomorac> ottomorac I will volunteer for did resolution

ottomorac: I will volunteer for DID resolution

markus_sabadello: We need volunteers for each specification and each group

<KevinDean> wip: I get it. We need volunteers for each specification. And we need volunteers within that who will volunteer for individual parts.

<manu> +1 to that approach

<KevinDean> ...We should get volunteers for each spec and have them volunteer for sections within the spec in the issues themselves.

<KevinDean> ...Happy to volunteer and this is a great opportunity to learn the W3C process in a low-pressure environment.

<markus_sabadello> Here is the Horizontal Review issue for DID Resolution v1.0: w3c/did-resolution#139

swcurran: Trying to figure out what work is involved
… Looks like this has been done before, for DID core

manu: Yep, this has been done for DID core. This should be easy. For DID resolution it will be more involved.
… Need most volunteers for DID resolution

swcurran: The privacy and security review is an intense bit of work. More than an hour to three hours

markus_sabadello: I will contribute to the DID resolution work. Not sure which group to focus on

<swcurran> timeline for completion?

markus_sabadello: For the DID one, it says DID explainer. Do we need a separate DID resolution explainer

manu: Yes
… unfortunately

<KevinDean> wip: I want to say that we should move on. We should send an email, let folks review what's required, and bring it up again next week.

<ottomorac> we should probably move on and send an email to get some volunteers

DID Core Issue: Abstract Data Model

<ottomorac> RESOLUTION 1: Align DID Core with the Controller Document specification (https://www.w3.org/TR/controller-document/), and attempt to remove language around the Abstract Data Model.

<ottomorac> RESOLUTION 2: When profiling the Controller Document for the DID Document specification we will use JSON as a concrete representation, with language describing options for alternative representations.

ottomorac: This is reviewing what we need for finalizing the abstract data model changes based on the resolution we passed

<ottomorac> w3c/did#855

<manu> w3c/did#855

manu: The first resolution has an issues that is tracking it. Issue 855

manu: I think this is ready for a PR
… Removing the discuss label
… ivan have we put in the media type request for CID
… I know we did the for application/did. Just checking now
… application/cid is not in there. We need to follow up on that

manu: Raising an issue against the CID spec now

<manu> w3c/cid#153

markus_sabadello: With regard to simplifying the abstract data model, this has largely been addressed through alignment to the CID specification
… in resolution spec we have removed the resolve representation function. This simplifies things
… There is still a question about using the INFRA mechanism to specify data structures. There might be a discussion about replacing that with just JSON

<Zakim> manu, you wanted to speak to using INFRA.

manu: I don't have a great sense of what might still need changes
… I dont think we should drop INFRA, because infra has a very clean map to JSON
… Will lead to questions around what you are doing with specific types of data
… For the DID spec part, there are areas of the data model spec that are INFRA defining the values of DID Core.
… You could argue that INFRA is an abstract data model. But there are members of the W3C that do no think this
… This is where i am struggling in the spec. We have been told to use INFRA, which arguable is an abstract data model
… We have been told by the TAG not to use an abstract data model
… A bit confusing
… I think we stick with INFRA and state the mapping from INFRA to JSON
… We have been told conflicting things. Challenging as an editor.

I am arguing that the data model section with INFRA should not be deleted.
… Then there are the production and consumption rules for different representations that can be deleted.
… Maybe the JSONLD section. While keeping the rule that we said, you cannot break JSONLD processing that exists
… There are judgement calls to be made here
… Can you have multiple representations of a DID document. E.g. in CBOR. How do we tell people it is possible, while complying to the one format JSON that we are defining
… That language needs to be put in here
… The semantics of what is meant by the properties must match across different representations

<KevinDean> wip: I think that was great. That sounds like where the group thought it was at. Some of the changes haven't made it into the spec yet.

<KevinDean> ...Question for Markus. How does that impact the resolution spec? Does that mean that resolve should always return application/did?

markus_sabadello: I agree, with manu we should keep the section about the data types
… and change the production and consuption section

<ottomorac> :-)

markus_sabadello: We still have a resolution option called accept, that allows you to specify which content type you want back
… This is inspired by HTTP headers
… So you can still specify if you want a DID document in a different representation

<swcurran> Thank you, Manu!

DID Use Case Document

<ottomorac> w3c/did-use-cases

ottomorac: This is just to kick off a discussion about what might be needed with the use case document

JoeAndrieu: We as a group have not decided what we are doing with the Use case document
… What new use cases might we add
… Might nthere be new editors. Not yet spoken to Phil archer the current editor, but he may not be available
… Asking the group for a review of the current document

manu: JoeAndrieu I think it is always a good idea to do another pass through the document to see if anything looks dated
… That might be it
… May be interesting to also cover new use cases that we are seeing moving to pilot/production
… e.g. the use of DIDs in physical documents
… Not majorly different, but some people have been suprised that there are printable versions of DIDs/VCs

ivan: Wondering if there are use cases that relate to the resolution document
… This is the only new thing we are bringing in in this working group
… You might answer that this has no end users, but I think it is worth thinking about

JoeAndrieu: Yeah, I like what you are pointing about about DID resolution
… Part of what we are talking about in the resolution architecture section, we could have usecases that give reasons for the different architecutres

<Wip> +1 I like that to

<KevinDean> wip: Is that a separate document or a separate section of the current document?

markus_sabadello: not sure what a separate document for DID resolution would look like.
… I think there are narrow use cases that use DIDs but not DID resoluition
… Makes sense to just have one document

<ivan> +1 to markus_sabadello

<Zakim> manu, you wanted to -1 separate document :)

markus_sabadello: What Joe said about querying multiple resolvers, is not really a new use case. But more of a security thing

<swcurran> +1

manu: I dont think we need a separate document. Adding a section or specific use cases that focus on resolution makes sense

JoeAndrieu: That is great feedback. We still need to figure out editors.
… Let me reach out to Phil and see
… But I think we should also send an email out asking for Editors to help support the document

manu: +1 to that. Maybe we could actively recruit some people who might want to get into the work of the community
… Some people are looking for places to contribute. This might be a great entry point

ottomorac: +1 to that suggestion

ottomorac: Moving on

<KevinDean> wip: There's only time for one issue.

<ottomorac> w3c/did#539

w3c/did#539

ottomorac: This issue is clean up herd privacy issue. Manu suggested closing this

Wip: lets ask Joe what he thinks ...

JoeAndrieu: I think maybe we close this and move on. Lots of separate threads on this

https://w3c.github.io/did/#herd-privacy

manu: I forget what the new term. Herd refers to animals some people dont like it
… So maybe its group privacy
… Fairly easy change to make

<TallTed> "crowd privacy" ... "mob privacy" ...

<TallTed> "population privacy"

JoeAndrieu: lets open PR get that in then close the issue

<ottomorac> Next Time: APAC Call

ottomorac: We are at time, next week will APAC call

<TallTed> 8pm ET next week. Use your computer calendars!

ivan: Reminding people in Europe we change to summer time. We will be back to the normal times

ottomorac: Thanks all

<ottomorac> m2gbot, link issues with transcript

<m2gbot> comment created: w3c/did#539 (comment)