DID WG Telco — Minutes

Date: 2021-06-01

Attendees

Present: Daniel Burnett, Ivan Herman, Shigeya Suzuki, Brent Zundel, Manu Sporny, Troy Ronda, Drummond Reed, Markus Sabadello, Dave Longley, Justin Richer, Ted Thibodeau Jr., Adrian Gropper, Kaliya Young, Amy Guy

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Dave Longley

1. Agenda Review, Introductions

Daniel Burnett: Typical notices at the beginning, then we’ll do implementation feedback, then the expected need to publish a second CR. If we have time left we can discuss did core issues and PRs – and we want to leave a few minutes for next steps for the WG at the end.
… Any requests for changes to the agenda?

2. No special topic call

Daniel Burnett: No special topic call this week, as soon as we need to discuss something extra we’ll do that again, but nothing in mind this week.

3. Notice of upcoming cancelled meetings

Daniel Burnett: The chairs and team contact will not be available on June 22. So the meeting that day will be canceled, no meeting on June 22.
… We wanted to ask for those present on the call for July 6th. I know that many in the US take extra vacation days off during that time. Please +1/0/-1 on having a meeting on July 6th.

Drummond Reed: -1 - it’s my wife’s birthday

Justin Richer: 0

Manu Sporny: -1 to have July 6th meeting.

Dave Longley: -1

Shigeya Suzuki: 0

Ivan Herman: 0

Markus Sabadello: 0

Ted Thibodeau Jr.: +1 available

Daniel Burnett: The July 6th meeting will be canceled.

4. Status of Implementation Feedback

Daniel Burnett: Manu, do you just want to give us a brief status update?

Manu Sporny: See Test suite and report

Manu Sporny: People are getting their implementations in just over the weekend we just got quite a few. That put us in a much better place. It does not remove the need to do another CR, we still need to do that. We’re starting to look better and better and once we get Mattr and UR final implementations in we’ll be in good shape for dereferencing/resolution.

Daniel Burnett: Any questions about the status?

Manu Sporny: Just to show people were implementations are now I’ll share my screen.
… I’m sharing a view of our implementation report. Shigeya has done some great updates over the last few weeks. We have summaries of implementations by DID method and by implementation which is great. For example, Veres One has an implementation from the Veres One Foundation and from the Universal Resolver. The UR has done implementations for other DID methods which is great.

Drummond Reed: Hooray for Markus!

Manu Sporny: Every single normative statement now has a list of every implementation that implements it. We have a tally per normative statement.

Shigeya Suzuki: Note: I just added summary by “spec statements” section as a draft. (draft PR)

Manu Sporny: For example 14 – that’s very healthy.
… We also search for insufficient implementations, we have 24 of those – that’s concerning. That includes hl, service, relativeRef, and some JSON production rules.
… This is fixed as of this morning, for canonicalId/equivalentId – these all came from a single implementation. I haven’t re-run the report, but once that’s done we should have enough here for a number of the things that currently don’t have enough implementations.
… You can run this report yourself.
… You can search for this information once we re-run and publish an update.

Daniel Burnett: So people are reading the notes please drop a link.

Manu Sporny: I’ll look for a good link.

Shigeya Suzuki: I just added the summary in the last hour.

5. Candidate Recommendation - take two

Troy Ronda: We have multiple implementations for canonicalId and equivalentId. https://github.com/w3c/did-core/pull/756

Troy Ronda: https://github.com/w3c/did-core/pull/756#issuecomment-852148628

Troy Ronda: I have requested that the “at risk” marker be removed for canonicalId and equivalentId.

Daniel Burnett: The chairs sent an email last week prepping the week about CR. There was a draft sent out and we gave 7 days for comments.

Manu Sporny: We wanted implementations to be done weeks ago and we have a number of features that have plenty (like 14). But there are also some features that aren’t sufficiently implemented.
… We had some things marked at-risk and we can just remove those if they didn’t get implementations. However, we didn’t mark some features at-risk like service/relativeRef – and no one has come forward saying they will implement.
… We didn’t mark it at-risk, we don’t think people will implement it and now we have to mark it at-risk and publish a new CR.
… So we’re having to do this because of these features.

Daniel Burnett: We have to do a new CR if we remove those features we need another CR – and we don’t have implementations for them. So we’re doing another CR where we mark those features at-risk to give us more time to keep those features, but if at the end of that time period we still don’t have sufficient implementations we can remove them without CR3.
… That would be devastating as a group to have to do that.

Manu Sporny: https://github.com/w3c/did-core/pull/757

Daniel Burnett: (To have to do a third CR).

Manu Sporny: We have the second CR PR link here in IRC.

Manu Sporny: Information about 2nd CR: https://lists.w3.org/Archives/Public/public-did-wg/2021May/0033.html

Manu Sporny: Preview of 2nd CR is here: https://pr-preview.s3.amazonaws.com/w3c/did-core/pull/757.html

Manu Sporny: List of changes since 1st CR: https://pr-preview.s3.amazonaws.com/w3c/did-core/pull/757.html#sotd

Troy Ronda: The point I was going to raise was that canonicalId and equivalentId now have multiple implementations. I was just trying to get on the queue to say those features should no longer be at-risk.

Manu Sporny: When I prepped the document, we didn’t have that quite. At this point we could probably take that out but we’d reset the clock again – just a few days, not a big deal.
… If for whatever reason we find out that those features weren’t implemented it could harm us. It doesn’t harm us to keep the marker for now and remove it later.
… If we remove it now, we’ll be in trouble if there’s any issue.

Troy Ronda: I do not think the at risk marker should be present.
… Both orb and ion have this feature.
… I don’t think these markers should be there.

Manu Sporny: We’ve seen things happen like that a few times before when it didn’t matter, and I’d just recommend we keep the marker here for CR2. If we prematurely remove it and there’s an issue we’d have to do a third CR. Let’s keep the issue markers that are in CR2, just to be extra safe.
… It doesn’t hurt us to keep them in there.

Troy Ronda: Those features are also included in the Sidetree spec: https://identity.foundation/sidetree/spec/#did-resolver-output

Troy Ronda: The implementations are present.

Daniel Burnett: Troy, this may not be obvious, the term at-risk may be confusing. The at-risk marker does not increase the likelihood of anything being removed. It just means that if something fails to get implementations, we can remove it without having to do another CR.

Manu Sporny: Specs don’t matter at this point, we’re looking for implementations… we have two (that we haven’t vetted yet).

Daniel Burnett: If your statement is correct, we don’t have to worry about it getting removed. The at-risk marker is just there to avoid having to issue another CR if something went wrong with the implementations. It is not an indication of a problem with the feature, or that the group thinks the feature should be removed. It’s a marker you put in a spec to avoid having to do another CR if the features haven’t been implemented.

Troy Ronda: The implementations have been submitted to the test suite. Not sure what additional criteria is being applied here.

Daniel Burnett: This question has come up by other people in the group over time. I’m happy to explain this in detail, we can spend some time now. Let’s just spend a few minutes on it now but if you need more time we should discuss with you and the chairs.

Troy Ronda: The implementation is based on us and Sidetree.

Daniel Burnett: There are no criteria involved here. What’s going on here is that there was a 7 day clock that started on Saturday. If we don’t have to change the doc, we can vote next time. If we have to change the doc now, we have to wait another week to vote. The change you are requesting doesn’t help anything.

Troy Ronda: clarification: Sidetree spec contains the feature and both ion and orb implementations have submitted to the test suite.

Daniel Burnett: We could technically mark the entire spec as at-risk, we just wouldn’t be able to publish CR because everything in the doc can be removed or change. It only hurts to not have it.
… Since the implementations just showed up this weekend we want to be extra safe too.

Manu Sporny: What is your specific concern? That the group might remove the feature later on?

Troy Ronda: My specific concern is that those features are critical to the did:orb method. Seeing at-risk is an uncomfortable position, I think.

Manu Sporny: If I were in your position, I’d not be uncomfortable. Those features aren’t going away if they are implemented. Let’s say one of the implementations has a problem – and we do have to remove those features from the spec. However, those features would be immediately registered in the DID spec registries. It wouldn’t make those features any less useful, it would just mean that did:orb/did:ion implementers would have to get together to make sure implementations match.
… The more likely scenario is that there actually are 2 interoperable implementations and people will dive in and make sure that there’s code that’s generating what’s put into the test suite and things will be good to go, it stays in the specification.
… Does that make sense or change your position in any way?

Daniel Burnett: Once it’s there, the marker doesn’t get removed until we go to another CR or go to PR.
… The determination for whether or not a feature stays in the spec is based on the group. The at-risk marker just indicates whether we have to have another CR or not.
… The at-risk marker is an editorial determination. The only thing the group has to do is: create sufficient implementations, which may already be the case, or two, if there are not sufficient implementations, have a discussion about what that means. Usually that means we have to remove the feature because we can’t move forward without sufficient implementations.
… I’m taking the whole at-risk marker off the table and making it an editorial/chair thing.
… We’ve spent too much time discussing this on calls, I’d be happy to make myself available and Brent too to explain what this marker means.

Troy Ronda: Was just looking for confirmation when it will be removed since my understanding was we met the criteria.

Ivan Herman: The parameter “hl” is non-normative, so it’s not relevant.

Manu Sporny: There were people confused about “hl” even those it’s non-normative, so I’m just trying to be overly careful and mark it at-risk.

Ivan Herman: If the Director looks at it, the same question will come.

Manu Sporny: Then we will explain.

Ivan Herman: I try to be absolutely negative and say we will have no implementations for any of these except version ID.

Manu Sporny: yes, Ivan is correct… :)

Manu Sporny: We will be left with ONE DID Parameter… :P

Manu Sporny: I think the group will say they find the feature useful.

Ivan Herman: So I tried to see what the consequences will be if at-risk is removed there and only version ID stays as a normative parameter. I don’t know what will be the reaction on that if that happens. We will have to have a clear answer for which we only have one entry that is normative.
… We may get questions about, if that’s so, why do we have parameters in the first place?

5.1 Media types

Ivan Herman: A somewhat similar thing that I did comment on is the media types. Let’s suppose – what is at-risk right now is did+ld+json. I expect us to have a problem with IETF and we’ll have to remove it. That would mean the only media type would be did+json, which is fairly inconsistent with the duality of JSON-LD and JSON.
… My feeling is, if that happens, then implementations should rely on application/json and application/ld+json media types and we wouldn’t define any new media types. I think it would be cleaner if what would be at-risk would be the IANA consideration section altogether.

Manu Sporny: We’ve unfortunately worked mime types into production and consumption rules. We can’t remove the IANA section without also making normative changes to the production/consumption and the general and specific rules of JSON and JSON-LD. It’s a big change, not impossible, but if we are going to make that change we should do it before CR2.
… I would really, strongly urge the group to not go down the path of removing mime types. Remember this whole discussion is about whether we can have a plus sign in the media type. If it sounds ridiculous, it kind of is. It has been talked to death, no one has said it will break the internet by having two plus signs.
… It’s also come to light that a number of other groups have asked for this at IANA in the past and have changed it at the last second for, what I’m claiming is an arbitrary reason given the conversations that happened.
… We’re putting the question back to the area directors at IANA to get an official answer back. We don’t have to register in the registry and we’re trying really hard to do that.
… I really don’t think we should take the media types out and push came to shove we can change it from a plus to a dash and we allowed that as a reason in our at-risk thing. The right thing to do, because of the way media types are structured is to put a plus sign in there.

Ivan Herman: You tried to convince me of something that I’m already convinced of. Yes, the pluses make sense. It is ridiculous; you are preaching to the choir.
… The problem is that we have to prepare for the case when this does not happen. I am not sure as far as W3C process is concerned – I’ve never faced this before. I don’t know if we can have an IANA considerations section without registering.
… That’s my concern.

Manu Sporny: I don’t think there’s a part of the process that says we’re required to register. I agree this is unprecedented. We have two options: Either force IANA to stop kicking the can down the road – and I’m happy to take up that fight. We’ve done a ton of work. Or we can cave and do a dash. If the Director says we have to register and we have to listen to IANA, then we will change it from a plus to a dash and register it.
… If, however, IANA comes back and lets us register it or the Director says let’s go ahead and address this because it will come up again in the future with things like CBOR-LD. In the mean time we will tell people to implement and we’ll have the at-risk to change it as needed.
… In all of the outcome scenarios we have a workable path forward. It allows us to do a CR publication without waiting.

Ivan Herman: What I would think will be done, and I will rely on Manu to do it, we will have to put in the request for the second CR, and we should call out this problem very explicitly in that request to the Director. It’s better to have that discussion now and not when we try to exit.
… We should put the request in about the problem we have and what does the Director want us to do.

Daniel Burnett: I agree with this. That was my concern as well. It’s not ok for the group to do something and this is what we want and we’re hoping the Director will agree. It pushes the problem to later on when it’s even harder to make a change.
… So do what you need to do – it’s better to wait a week or better to put the notes in the CR and “it will be one of these two” so it’s very clear.
… Depending on what the Director tells us. And implementations depend on this.

Manu Sporny: I’m very concerned. Item 1: link to at-risk marker.
… It says that depending on the discussion with the IANA group the media type could change or spec changes could happen. I’m very nervous about saying there’s one or two potential outcomes. We might get a surprise. We’re not getting good feedback in a timely fashion. I don’t know when we’re going to get more definitive on this, so I tried to write the at-risk marker as broadly as possible.
… Meaning, we will talk to IANA and we’ll update the spec. We had two choices before and we were wrong, so that’s why we changed the language.

Daniel Burnett: I understand that, we don’t control the world, only our own work. We can say whatever we want. We don’t control IANA, the IETF, the Director. I’ve been in many WG with similar issues, we’ve decided that this is what we have to do because we can’t wait. I understand – you’re saying let’s take the risk of trying to get the thing we want. Because maybe the Director will say you don’t have to have it registered today because W3C doesn’t control that.

Daniel Burnett: But that risk you’re asking to take delays the conversation to a very late stage if we’re wrong and it makes me nervous as chair. I’d honestly rather have us pick something today and do it – and put a warning in the document that says we have these alternate registrations in the future. As chair, I’m really nervous about doing something that is assuming the world will change in some way.

Ted Thibodeau Jr.: I just posted this comment early last night. I saw recently another spec, and I believe it was a W3 document might have been IETF RFC, but pretty sure W3. The IANA considerations section said “until IANA says you can’t do this, then do this other thing”.
… IANA doesn’t work like W3 at all, it doesn’t set time limits other than “give us a response by date”, they just wait for work to be done. I think we should do the right thing based on the way the system works. That is to add the second plus sign and to advise people to use it. That’s the way the system was designed.
… Nobody has been able to say here’s why we can’t do this – and IANA uses that pattern for making decisions, whether it breaks things – and this doesn’t break things. We should do it.

Justin Richer: +1 to TallTed’s statement, but seriously don’t die on that hill if it comes to it

Ted Thibodeau Jr.: I have been an internet user and standards worker for a very long time and it’s time for IANA to get off the stick.

Daniel Burnett: What is the consequence to us if we do what Ted is saying?
… This is the mime type, this is what we recommend you use until we’re told otherwise by IANA.

Manu Sporny: I don’t see this as a risk and here’s why. We have basically said we will change it to whatever works at the last possible moment, and it’s not to push the decision off, but it’s because IANA has not responded to multiple requests.
… We’ve done what was said and we’ve said “Ok, we’ve done the work and this is what we’d like to register” and we haven’t gotten a response back. We need to get that response before we go to PR. We need to have a discussion with the Director and the area directors would also weigh in, ideally. Whatever happens, when they come back to us – and they say “You have to use a dash” for example – we’ll just update the spec and that will be that.
… I don’t see this as a risk because we have all paths mitigated through the at-risk marker and we’ve thought, I think, about all the possible outcomes.
… We need to hear from them otherwise we will continue to not know.

Ted Thibodeau Jr.: Maybe we can include in the “until and unless” language something that says “an erratum [or doc change, given the movement to maintainable/evergreen W3Recs] will be published if/when IANA says this is absolutely no good”

Daniel Burnett: I think that answers my question. Ivan – has this addressed your concern to at least enough satisfaction to not have to change the at-risk marker from what it is today?

Ivan Herman: I would like just to speed up things – I would like this question to go to the Director today.
… And not even wait until the point where we submit a publication request for the second CR. I think we should have done that earlier to be honest but we were all hoping this would be solved.
… We should involve Wendy too as IETF contact. We should involve them and hear back from them.

Daniel Burnett: Right, I understand.

Manu Sporny: I’m happy to try and write up the background and send the links and that kind of stuff and pose the questions and send that.

Ivan Herman: Philippe, Ralph, and Wendy.

Daniel Burnett: Depending on what we hear back that may restart the clock. I agree we should get that answered before the next CR.
… It would be helpful to point out the timing in that email. To say we’re only doing a second CR to get sufficient implementations on a few features/verifying we have them.
… We’d prefer the conversation to have a resolution within a week.

Ted Thibodeau Jr.: (I’m quite certain that IANA reg is not required by W3M, even when it’s discussed in a Rec, because of the number of “oh, we never got around to updating/registering that” conversations that have been happening around RDF media types.)

Ivan Herman: One minor thing to add – this is a feature at-risk for very different reasons. It’s not because of no implementations. It’s only because of IANA isn’t getting back to us.
… That must be made clear to the directors. We do have implementations using this feature.

Daniel Burnett: The question of whether we will be able to vote one week from today – depends on the outcome of this conversation and if anything needs to change in the Saturday’s draft.
… I know you want to talk about next steps for DID WG right now, Ivan.

6. Next steps for DID WG

Daniel Burnett: I’ll tell you what though, I’ll add that as the next topic – would you be willing, Ivan, to just say a couple of words about that and what kind of options there might be, but we’re not going to discuss right now just to think about it.

Ivan Herman: The formal situation is that the charter runs out end of September. So we have to have a clear path on where to go with that. I am hoping by end of Sept. we will have DID published and the charter is completed, maybe not because we need a 3 month extension. But we have to think about what we do after that.
… There are two possibilities that we can consider – one is to follow the model that many of you know from the Verifiable Credentials WG, that we charter a group called a maintenance WG. It’s there to keep the legal side of things and to republish as needed but the WG is mostly inactive and work is done in the CCG.
… The other possibility is that the group believes that there are things that should go standardization track after this – in which case we have to go through a more complicated chartering because we have to write a new charter for new work. A maintenance charter is simple.
… A new charter takes time and I have to write it, it could take 1-2 months at W3C and then an AC vote after that, so we need to think about all that quickly and we should have a discussion which we want to go.

Drummond Reed: Good summary, Ivan

Daniel Burnett: With that I will thank our scribe.

Dave Longley: Sure.

Drummond Reed: Great job, Dave

Daniel Burnett: You are the success of the group, it’s all of you here who have made this possible. We’re very grateful for all the contributions.