Meeting minutes
@burn I'll try to scribe, but need some refresher.
burn: Testing scribe.
… and other test.
… We are really hoping for people to attend APAC calls.
<denkeni> Just joined here from APAC!
burn: Thank you everyone for joining. For those joining us a first time, introduce yourselves.
Agenda Review, Introductions
burn: agenda is usual review and introductions, and details about tpac spreadsheet.
… and then usual issue and pr review.
mashbean: From Taiwan, in ministry of digital affairs. We joined to use DID with our digital infrascture in Taiwan. Which is why we are here.
… ministry of digital affairs
denkeni: I work with Taiwan ministry digital affairs, technical consultant to work with adopt DID and VC in Taiwan.
… and plans to join tpac in person.
ChristopherA: who else is in Pacific?
<manu> ChristopherA: I wanted to ask, be aware of who else is in Pacific, useful to know who they are...
shigeya: I am from Keio University, I'm quite happy we have APAC time zone call, and happy to see the Taiwan folks.
Geun-Hyung: I attended the DID WG some meetings last years, but missed many. but quite happy for APAC times. I work for Gooroomee University, I work on decentralized web
<Geun-Hyung> Gooroomee
TPAC Attendance
burn: when we sent the agenda, the link wasn't quite right. This is the correct link.
<burn> ^ attendance sheet
burn: this is a google spreadsheet where we'd like you to sign if you are coming, so we have an ideas on attendance.
… if you have any problems accessing, email the chairs.
DID Core Issue/PR Processing
<burn> https://
burn: here is the general link for the issues, and Manu will lead us through.
manu: I'm going to start off to re-cover some ground so that APAC folks will be up to date.
<manu> https://
manu: first class 3 issues.
w3c/did-core#854
manu: We brought up the question on the US call a while ago, #854 is about normatively referencing the controller document (VC group).
… It is useful for non-DID uses to use the DID core controller document.
… This is the new controller document specification.
<manu> Controller Documents 1.0 https://
manu: Basically a DID document using URLs not DIDs.
… This means that our DID Core document will need to make normative references to the Controller Document.
… that is standards track in the VC group, not ours.
… We considered reference it normatively, and there is some agreement for that to happen.
… that means that document will go through a bunch of 're-review'
<manu> W3C TAG: w3ctag/
manu: and we expected it to go easily without changes, but now in the VC group there are some people who want some changes.
… In particular reviews W3C TAG and a privacy group.
… but they are reopening issues that we've closed before.
… The path we are on is to normatively reference the controller document once it stabilizes.
… So the question for this call, is does this APAC group have any concerns or support?
denkeni: question, these controller document are in another group, and do we have to join that group to contribute?
manu: Yes, you can join there, but this group has a lot of authority about that content, and any objection we have carry weight. I am editing both documents, and trying to keep the consensus if raised in either place.
… you can raise in either place for consideration.
denkeni: Do we have a diff tool to compare them? We have some DID core documents now, do we have some way to see what has changed in their controller document.
manu: yes, but unfornately in this case, there is a subset of the text was copied over to data integrity spec, which then went to vc controller document, so now people are asking for both editorial changes and normative changes.
… So compare is hard. You to have both documents and specs side by side.
… No automated tool right now, unfortunately.
<burn> +1 to waiting for VC CR
manu: I'm going to mark this issue as x? but I'm going to wait some until the controller document reaches candidate rec CR, once it does we can start referring 854
c/x?/ready for PR
… probably not until end of November.
w3c/did-core#859
manu: Next is #859 is finding a path forward to contexts.
… we discussed this last week in the US/EU call.
… the general consensus is that we can create a new v1.1 context, but there are some changes that some members would like to make, but in a backwards compatible one, and say you can use either 1.0 or 1.1 context.
… the updates are a new version of multiply and json web key, to keep it in the direction of the vc controller doc spec.
… any did method could the new 1.1. context if they want to.
<denkeni> sounds great
manu: any support or objections/
… I'm going to mark this "ready for PR". This does not mean it goes in as is, we will review it again.
w3c/did-core#850
manu: Related is issue #850, about json web key to 2020
… This is one of the updates that we need to do if we do the 1.1 context, we would change the name of that type, adding multibase
… This is just the upgrade without the date.
danpape: quick question, trying to understand, where is the PR?
manu: A 'ready for PR' for an issues is added when we have a good idea so that we can create a PR to address it, with some general consensus.
… then the editors come back with a PR later, and then come back here. If no objections after seven days, we merge it then, and close the issue associated.
… we would update from jsonwebkey 2020 via context 1.1 and text in spec.
… done, it is marked 'ready for PR'.
ChristopherA: The "ready for PR" things will be gone through by the Editors, but that doesn't mean that you can't pick up a "ready for PR" issue. You don't have to be an Editor to raise PRs.
ChristopherA: Ones that are ready for PR are a good opportunity to learn.
manu: any member of the working group can raise a PR, not just editors.
<denkeni> Understood. I've done a simple PR in did-core and got merged before I joined DID WG lol.
w3c/did-core#838
manu: Next is issue #838, I don't expect us to get a decision on this, but wanted to raise it.
… what do you do with the did document when you don't know the media type, or it is incorrect.
… should you reject it, continue to process it, etc. What guidelines are needed?
Media Type precision: https://
manu: (elsewhere, vc-data-model spec) basically tell people that fairly often the media type is wrong, or guess, or wrong file extension, or misconfigured.
… In those cases, should we give guidance for did document?
… for instance, we get app/json not did media type, should they continue processing or through error.
… the vc model spec says it is ok to have an algorithm that identifies the document, and there are certain things you can check for.
… for instance, the context at top, or some did document specific details.
… it is up to you.
… so the question is that we should have a parallel section to the did spec that is in the vc spec.
ChristopherA: Media types is using web as the transport mechanism, there are other transport mechanisms used by other parties. I'd like to say something to the extent that it's ok, when it's web based, or using a different transport, to analyze the received document and make a decision. I'd like to see that as a PR.
manu: any other feelings, one way or another?
… I suggest that it is up to the application, but as a lot of applications are not depending on the media type exclusively.
<denkeni> +1 to up to the application
manu: are there any objections to writing something along the lines of the vc spec into did spec.
+`
+`
<ChristopherA> +1
The split of the registries
I'm marking this ready for PR.
manu: The next topic is the did extensions doc.
… The original DID group needed a way to register extension, but we didn't want a centralized registry.
… that it was ok for other ways to list.
… we called it a registry, but a number of us were uneasy about actually a centralized registry.
… we wanted a decentralized method for a decentralized identifiers
… So we called this 'extensions'
… but this extension list become huge, especially the did methods section
… and of course a lot of other property.
… So we discussed splitting this document, subdirectories for did methods, another X and a third for Y.
https://
manu: The group seemed fine for the split, so I have done so.
https://
https://
https://
manu: The process is the same, and then there are three subdiretories, properties (like verification method, assertion method, key),
https://
manu: next is resolution related values, referencing, meta, parameters, etc.
https://
manu: and then we have all the did methods in the third.
… that is where things are right now. Some old links broke and we are trying to puzzle out how to fix.
… Pierre suggest that maybe we do it differently, and instead do links like
PA mentioned, instead of doing this: https://
manu: (Pierre is our W3C contact)
… let's not use subdirectory but full names.
… I'm not sure the benefit, but wouldn't object.
… any thoughts on what we should do.
… we'd keep it in the same repo, but different TR space URL, without slashes.
JoeAndrieu: I like the longer pattern.
… rather than directories.
denkeni: Instead of directories, I'd like to see an overview, as a long list splitting out in several parts, I can only see that from GitHub. Is there a better TOC to have overview of documents available.
manu: two ways: for did extensions, we can have a top level TR, what about did core and did resolution and rubric, etc. Where does someone go to see that overview of all.
<Zakim> JoeAndrieu, you wanted to say it sounds like vc-overview
JoeAndrieu: In the VC wg, Ivan created an overview document, it would be a good idea to have the same.
manu: maybe a did-overview document
https://
manu: basically a minimal cut out/summary of all the document.
https://
manu: The other thing we can do, the vc-data-integrity spec, we have a thing at the top that says related specifications in the header.
… I suggest we do both.
burn: historically, I'd see W3C custom website that does this.
… other groups at W3C have also done this.
… W3C seems to be moving toward not customizing their website.
ChristopherA: I'm maintaining a lot of specs for the wallet developer community and we're also running into this problem. I have to strongly encourage both answers. You need to have at the top, in the document itself, someone just gets the link to take them to the child document, they don't know it's a child document.
<denkeni> +1. documentation hierarchy hell lol
ChristopherA: You need to have that in these documents in addition to the non-normative overview at the top (the overview document), for people approaching it from a top-down. People enter from deep links, we don't do a good job of getting them back to the overview.
burn: not time for resolution. Any final comments?
manu: No final comment! Thanks!
burn: thanks to those who have attended this. Your attendance keeps us doing this call. We look forward to joining us in October for the next APAC call.
<denkeni> See ya in TPAC!
Ciao! folks!