DID WG Telco — Minutes

Date: 2020-09-01

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Daniel Burnett, Manu Sporny, Markus Sabadello, Dave Longley, Brent Zundel, Kaliya Young, Justin Richer, James Qu, Amy Guy, Michael Jones, Jonathan Holt, Orie Steele, Daniel Buchner, Adrian Gropper, Pamela Dingle, Dmitri Zagidulin, Wayne Chang, Drummond Reed, Joe Andrieu

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Dave Longley, Amy Guy, Manu Sporny

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: Agenda for today is talking about the next topic call, talk briefly about the virtual F2F TPAC.
… Then we’ll have a status report on service endpoints and there’s a bit more time on that and see where we can get with 20 minutes. Then move onto our regular status check.

Jonathan Holt: +1

Manu Sporny: It may be useful to review the process of proposals that are made on the special topic call and when those are viewed as effectively consensus from the group. Jonathan asked for some clarification there and I’d like that as well, perhaps not remembering the process.

Daniel Burnett: That’s fine, right after the F2F reminder.
… Please remind me if I skip that.
… Anything else?
… Ok. Is there anyone who hasn’t reintroduced themselves in a long time and would like to?
… How about Ivan?
… I’m sorry, go ahead Mike.

Michael Jones: I’m Mike Jones. I work on identity standards at Microsoft. I’ve tried to built a JSON/REST stack to solve identity on the Web including Oauth, JOSE, WebAuthn, FIDO2 specs. I try to keep things simple enough that devs will use them and secure enough that they’re worth deploying.

Daniel Burnett: Ok, thank you.

2. Next Topic Call

Daniel Burnett: The next topic call will be in approximately 7 hours from now and will be on the test suite. Although it is not required to have a test suite before CR, it is highly recommended since you can’t exit CR until you have sufficient implementations which requires a test suite.

Manu Sporny: https://github.com/w3c/did-core/issues/384

Daniel Burnett: It’s also good practice and a lot of the work you do has to do with what you discover when you build tests.

Orie Steele: I made this thing based on the last conversations we had regarding test suite… https://github.com/OR13/did-core-tests …. and I am cowering in fear of amy’s list….

3. TPAC FF2F

Manu Sporny: Amy has put together a fantastic review of every normative statement in the spec, whether or not its testable, proposed changes, so on. If you have a chance to look at that today before the special topic call please do, it’s a great set of work.

Manu Sporny: https://github.com/w3c/did-core/issues/384

Daniel Burnett: F2F meeting will be virtual for TPAC. We had announced a week. It turns out that IIW was that week. We didn’t know that and we forgot to check that. In the doodle poll no one marked themselves as not being available and we had a laugh with Kaliya about that. The meeting will be now Nov 2nd-5th. Same times. We will send an email out.
… There’s a link in the agenda.

Daniel Burnett: https://www.w3.org/2019/did-wg/Meetings/F2F/2020.11.VirtualTPAC.html

Daniel Burnett: You can see the dates and times on there, please reserve them.

Kaliya Young: Note on IIW, early bird pricing ends next week, if you’re coming, go buy your ticket.

Daniel Burnett: Ok, thank you. Any questions about the timing of our TPAC meeting?

Kaliya Young: http://www.internetidentityworkshop.com

4. special topic calls and how normative they are

Daniel Burnett: Ok. The next topic is the one that we added. Special topic calls and how normative they are, essentially.
… Brent and I have been very careful to try and draw a line between meetings that are essentially official – decisions are made at them but there’s a time for confirmations. This meeting slot is the official slot. The special calls are extra and we don’t want people to feel like they have to attend those.
… You can come up with tentative resolutions, but they don’t matter until you bring them to the group. You can bring them up on a call but our favorite is via the issues.
… Those resolutions from the special calls are non-binding but they need to be reflected in an issue or as a pull request. If there’s a disagreement on the PR and you were on the call we might ask “What changed your mind?”. If you weren’t, your input can be considered new.

Brent Zundel: https://www.w3.org/2019/did-wg/WorkMode/#communications

Brent Zundel: I’d like to bring everyone’s attention to our official work mode document.
… This is the communications section, it talks about rules and guidelines around teleconferences. Though we differentiate between our weekly official time and the special topic calls – the rules around resolutions made in both are really the same. The reason I say that is because even the resolutions in our official call still requires 7 days with a call for consensus.
… According to the group – we have to do that for our regular calls anyway. We feel very strongly that we need those 7 days.

Daniel Burnett: The difference I was trying to draw between the two: If you don’t attend a special topic call and don’t read the minutes, it’s still not a binding decision, the special topic calls weren’t intended to create binding decisions. Whereas, the official call, if you don’t attend it and you don’t follow the minutes, a decision could be made that you didn’t see.

Brent Zundel: An example of a differences is that in our regular call we might come to consensus that we want a set of PRs to be merged immediately. On a special topic call we wouldn’t do that, we’d say raise a PR so we can continue the discussion.

Ivan Herman: This is a coincidence, but I will deploy a separate page soon on the website that lists all of the resolutions that we’ve made on the calls, strictly separating the ones made on the official calls vs. the special topic calls. The list itself will update itself.

Manu Sporny: Yeah, I just wanted to see – if, given those definitions, if jonathan_holt thinks there was a process violation.

Jonathan Holt: No. I agree that those were non-binding. And important to get work done, and I just want to make sure that if people were on vacation or missed the 7 days, I want to make sure that we give people enough time to object. We bring things back to the group to ensure we have consensus. I want to make sure we have a broader discussion of such an important topic.

Manu Sporny: Just to go into that a bit more. I have one concern with the process. The resolutions that we made were to write a PR. That was the outcome of the special topic call – once the PR is written you have another 7 days. In this particular case I don’t think there’s any issue. I am concerned about people thinking that the special topic calls… that it’s possible to completely ignore them.
… And if the resolutions aren’t brought up on the main call then that’s grounds to object at some point in the future. You can always object on the PR. I think that’s our gating factor. The proposals and resolutions on the special topic calls are there to make steady progress. The minutes are posted on the mailing list.
… A fairly negative read of what the chairs have said is that “Oh, I don’t have to pay attention to those special calls and it will be raised on the main call.” That’s not always going to be true. If the editors create a PR based on something from the special topic call and someone comes and says “but that doesn’t matter, I wasn’t there”, I think that’s a problem.
… I want to make sure we’re not opening ourselves up to “It happened on a special topic call, it doesn’t count.”

Daniel Burnett: I hear you, Manu. We were trying to keep the process as light as we could get away with. There is an ability for someone to be disruptive in that manner. At the time that we discussed this we also said things like “Don’t be a jerk.” And that means, “Don’t actively ignore other discussions going on on a topic you care about just to complain later.” The chairs will not look favorably on that.
… If it turns out that someone who really cares about something was on vacation for 2 weeks and missed the 7 days – and wants a chance to look at a decision that was made, we can make a call there.
… We can get really specific about process here but I think people won’t like it. Just don’t be a jerk and it applies in both directions.

Manu Sporny: That feels clear to me :)

Brent Zundel: I would like to second “nobody be a jerk”.

Manu Sporny: +1 to that

Daniel Burnett: Any other questions/comments?

Dave Longley: +1

5. Service Endpoints Status Report

Daniel Burnett: I don’t know who was going to do this – go ahead Manu.

Manu Sporny: The last special topic call was on service endpoints. We had a good discussion starting off. The thing that was effectively raised toward the end was whether or not we need to be able to express service endpoints in DID documents at all.

Manu Sporny: https://github.com/w3c/did-core/issues/382

Manu Sporny: As a follow up to the discussion, we raised an issue, #382.
… It was raised as a suggestion that we didn’t need to express them in DID documents and discussion continued from there.
… On the special topic call, we did seem to agree that we should talk about service endpoints and their privacy characteristics in a non-normative appendix in DID core.

Ivan Herman: Minutes of the latest topic call on service endpoints

Manu Sporny: If you do service endpoints wrong, you can violate privacy, it can be a GDPR/etc problem. We can talk about it more.
… The second resolution was that we should have an abstract data model in the DID spec for service endpoints (and we already do). During the conversation it sounded like some people thought we didn’t have that or shouldn’t or whatever. The other resolution that we would have an abstract data model in the spec in normative language effectively like we’ve done with verification methods.
… The third resolution had to do with service endpoint extensions. How do you express them, how do you talk about types of them, etc. The resolution is that we should describe how you extend service endpoints in the DID specs registries.
… 382 follows it up asking whether or not we need to express service endpoints in DID documents at all. The discussion is not about eliminating service endpoints, no one is proposing that there. The proposal is – should we suggest that people put them in DID documents or through some other mechanism like a VC or a DID Auth protocol or DIDComm, etc.
… There are lots of comments there and every variation of what could possibly happen. It’s a good thread to catch up with where people are. If you’re interested in the topic, please put input into that issue.
… I don’t know if anyone else would like to add anything with respect to where we are with service endpoints.

Markus Sabadello: I wanted to add that during the special topic call – I made a comment that we didn’t have that much time to discuss. It was about registering service endpoints types in the registries. It was related to extending the service endpoint data model. It was about whether service endpoint types should be registered, I have some opinions on that.

Adrian Gropper: A quick note, I think we need … from the glossary project we put a comment in there, I think we are to have the concept that some service endpoints are not normatively described in the spec, they are option but if you do the data model is normatively described. The others are just the others. I think we have some potential to get to consensus if that’s a good way to think about it.
… Did I say something beyond the resolutions as described beyond what was described by Manu.

Manu Sporny: I said on the call, yes, that’s one way you can think about it. I think it would be challenging to get consensus around a specific number of service endpoints. I don’t think the discussion isn’t around that or the number of them, right now it’s more about how you communicate service endpoints. Again, I don’t think anyone wants to eliminate them entirely, it’s about how to communicate them, whatever they may be.
… I don’t think we could pick up your thing and get consensus on it because I think we have to get the first discussion out of the way first.

Adrian Gropper: But the sense is that some service endpoints will eventually be normatively described in the spec?

Manu Sporny: At present, it looks like nothing will be, we will describe an abstract data model but not put any specific ones in DID core. But we’ll have an extension mechanism that will allow people to add them. They can be normatively described outside of the DID core spec.

Drummond Reed: Adrian shouldn’t feel that even if there are none described in DID core, there may be descriptions and examples in the implementation guide. It’s a subject we should pay attention to.

Daniel Burnett: We’re reaching the end of our time for this topic.

Manu Sporny: What are the next steps here? We’re collecting data on that issue, please put information there. The editors will act on the last special topic call. We’ll create a non-normative appendix PR and talk about extensions and privacy.
… We will make sure to keep the abstract data model for service endpoints in the specification and create a PR to talk about how to extend via the registries.
… Noting that Markus has some concerns around that.

Daniel Burnett: I answered Dave Longley – he had asked informally if there will be another special topic call on service endpoints.

Manu Sporny: Yes, if the topic doesn’t terminate. Dan Buchner has called for another special call.

Daniel Buchner: Yes, apps and services, the 99% of identity that isn’t VCs, etc.

Manu Sporny: Yes, there may be a special call around that which is related.

Daniel Burnett: Ok, anything else? Ok, thanks.

6. Core issue status check

Daniel Burnett: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

Daniel Burnett: https://github.com/w3c/did-core/issues/119

Daniel Burnett: We finished an explainer. We offered a document for the group to review, Ivan gave us comments, we’re working through it and we’re close. Brent are we close, done?

Brent Zundel: There was some additional text we might throw into the OID section.

Daniel Burnett: We might start the TAG review without the privacy and security review – we can always add that later. We want to make sure we can get this started. It can take them a month or two before they even look at it.

Daniel Burnett: https://github.com/w3c/did-core/issues/104

Daniel Burnett: We are leaving this open just to make the transition easier.

Daniel Burnett: https://github.com/w3c/did-core/issues/105

Daniel Burnett: This is similar, same thing. Left open for the same reason.

Daniel Burnett: https://github.com/w3c/did-core/issues/205

Daniel Burnett: Justin, unknown properties.

Justin Richer: There is a PR #362 that relates to this. Once again, I am not enough of a JSON-LD expert to really understand what’s going on here. At least I think #362 relates to it.

Daniel Burnett: I’m scrolling up to look for that link and I don’t see a reference to it.

Orie Steele: 362 has merge conflict and not response from pr author…

Justin Richer: Yeah. I just opened up the PR to see what might be addressing this. This is not addressed.

Daniel Burnett: Can you take a look at this and write some kind of status on it? Whatever you understand the status to be on a status in the issue? Whether it needs a PR or that PR is not good enough for X reason. I know this is a big topic and there are disagreements about this too.

Justin Richer: Fundamentally the group needs to land on a solution across representations that makes sense. It’s my view that we should take the loose JSON extendability by fiat model. But if we don’t do that, we need to be explicit about that one way or another.
… Orie is saying in the issue tracker about addressing it with mimetype, etc.

Daniel Burnett: I’m thrilled that you’re intrigued because it means you can ask that in the issue.

Michael Jones: I support Justin’s position to just allow not understood properties should be ignored, we already say that in the JSON section. We should say that in the abstract data model section.

Daniel Burnett: Just be prepared for a discussion if the unknown property is “@context”.

Daniel Burnett: https://github.com/w3c/did-core/issues/202

Justin Richer: I think this is fine.

Manu Sporny: I don’t know what dave is trying to say in two of the sentences, just asked for clarification

Dave Longley: I will take a look at 362 and see if that can get resolved
… Looks like Manu commented and I need to take a look at 362.

Daniel Burnett: https://github.com/w3c/did-core/issues/324

Adrian Gropper: I think we need to hold off until we make more progress on 324.
… #382 also relates to this. I think we have to go further with 382 before we can revisit the privacy issues.

Daniel Burnett: https://github.com/w3c/did-core/issues/266

Daniel Burnett: So, this is where it gets interesting. You asked the submitter for feedback on July 28th. It’s been more than a month.
… This is a case where, as a chair in the WG, I suggest that you change your comment to not say waiting for feedback but give a deadline and what will happen at the end of that deadline if you don’t hear back from that commenter.

Manu Sporny: We decided it’s a no-op for us and we’ll close in 7 days unless there’s an objection.

Daniel Burnett: Yes, thank you.

Daniel Burnett: https://github.com/w3c/did-core/issues/174

Daniel Burnett: There’s a PR that’s been merged, that was referenced – can you please take a look at this, Mike?

Michael Jones: ok.

Daniel Burnett: It looks like some work has been done to address your initial issue.

Michael Jones: Ok.

Daniel Burnett: Thank you.

Daniel Burnett: https://github.com/w3c/did-core/issues/341

Daniel Burnett: Assigned to Christopher. Manu – you had the most recent comment. I assume Christopher’s not on the call.

Manu Sporny: Christopher is not on the call.

Daniel Burnett: Right, so your final comment is that we need more specificity to move forward.

Manu Sporny: I can say still waiting, I doubt we’re going to do anything about this.

Daniel Burnett: I think that’s the right comment to put. Just be more explicit that unless we hear from him – it’s not a 7 day close because he’s a group member. But this issue is on track to being closed with no action without more details.

Manu Sporny: Ok, writing that.

Ivan Herman: My question/comment, the whole CBOR issue is still unclear to me. We don’t have agreement on how we will use CBOR as far as I know. Until that is solved, this issue should probably be left open because we don’t know.

Michael Jones: I put this in the issue, but to be clear, the WG doesn’t have to be involved to register tags at all. The IANA policy just needs a stable document that can be anywhere.

Daniel Burnett: Chair level comment – you’re right, Mike. Anyone can request to register a tag, if the tag is related to something we’re doing, then there might be a desire/request for the WG to be ok with it. That’s the only caveat. But you don’t have to wait for anybody to do it.

Michael Jones: Yeah, I agree. To the extent that he proposed specifics to the WG we should look at it, but we needn’t block on this. I’ll say that in the issue.

Manu Sporny: Agree with everything that’s been said. I will say that there are other CBOR issues that are more specific and actionable. I’m going to say that we’re going to close this one because we have specific suggestions in other issues – and we should close as a duplicate unless he says otherwise.

Daniel Burnett: https://github.com/w3c/did-core/issues/340

Jonathan Holt: I was going to remove the section in the CBOR … where keys must be byte strings – to open the doors for CBOR-LD in the future. I want to make sure I have a valid representation of a signature.

Daniel Burnett: Please summarize that in the issue itself?

Jonathan Holt: Yes.

Daniel Burnett: https://github.com/w3c/did-core/issues/338

Daniel Burnett: Thank you.

Jonathan Holt: I was going to remove the service endpoint based on our previous discussion and the proof section mostly because the CDDL is not necessarily conformant because we’re in flux. I can close this.

Daniel Burnett: Any objections to closing/

Dave Longley: s/closing\/closing?/

Daniel Burnett: Go for it.

Daniel Burnett: https://github.com/w3c/did-core/issues/185

Dave Longley: s/closing\//closing?/

Daniel Burnett: Any comment on this, Orie?

Orie Steele: I think we have pretty much eliminated the need for this ticket. The consensus appears to have been that the verification method type defines supported algorithms both for signatures and key agreement. And that’s up to the verification method author that creates the it to decide to allow/disallow a particular set of encryption/signature algorithms.
… I think when we merged JSONWebKey we added support for the algorithms in IANA and we can close this.

Daniel Burnett: I suggest you say that in the issue and do a 7 day close… actually, no, I leave it up to the core spec editors to say if it’s ready for a 7 day close.
… But go ahead and make your arguments for closing in the issue, I think you’re probably right.

Daniel Burnett: https://github.com/w3c/did-core/issues/367

Daniel Burnett: This is administrative.
… Did this already happen, Orie?

Manu Sporny: No, it should be assigned to me.
… There are issues in DID spec registries that should be in DID core and I took an action to move them and haven’t done it yet.

Daniel Burnett: https://github.com/w3c/did-core/issues/359

Daniel Burnett: Daniel?

Drummond Reed: This one is deep into the service endpoint discussion.

Orie Steele: in a world where every json property can be a string, array or object…. type concious developers cry tears of sadness.

Daniel Buchner: So, right now the service endpoint property is polymorphic, it could be a string or an object of stuff. Originally, I wanted it to be an array … and then Orie said it should be object period. I don’t know what the next move is without getting more commentary and then everyone makes another property underneath and it’s non-standard.

Daniel Burnett: So is there any consensus around any particular approach here or not?

Daniel Buchner: I don’t know think people know or they don’t care.

Daniel Burnett: Yeah, you should raise awareness and maybe do a poll. You may only get the two of you still.

Brent Zundel: PRs are really good conversation starters. That may bring people out of the woodwork to say “Noooo”

Daniel Burnett: Good idea, create a PR if you want instead of a poll since that’s where you’ll end up anyway. Anyone can do that, not just Daniel.

Amy Guy: burn, I updated the issue - we have about converged in a PR so this should be closed soon

Daniel Burnett: https://github.com/w3c/did-core/issues/122

Daniel Burnett: Status is that this will be closed when another PR is merged. Oh, Amy just put that comment in, thank you.

Daniel Burnett: https://github.com/w3c/did-core/issues/368

Daniel Buchner: So, I think that this is resolved.

Daniel Burnett: If you think it’s resolved and you’re the submitter you can close it.
… Let me just ask quickly – would anyone object to closing this?
… No objections, just make sure to leave a comment of why you think it’s closed.
… Or why you think it can be closed before you close it.

Daniel Buchner: Done.

Daniel Burnett: Cool.

Daniel Burnett: https://github.com/w3c/did-core/issues/339

Jonathan Holt: That’s mine. It seems that people still have reservations about CBOR but they seem to understand how important it would be in the future state. And the emerging support for CBOR-LD. Other than the byte string should be extensible … using the framework Manu presented at the F2F, I don’t see why it should be marked as at risk.

Daniel Burnett: Ok, we can leave it for now.

Brent Zundel: is it still marked as “at risk?” I’m not finding that in the spec.

Daniel Burnett: I am going to do a very important thing before we end today’s call.
… Anything else from anyone?

Daniel Buchner: manu: orie: https://github.com/w3c/did-core/issues/359#issuecomment-684960017

Daniel Burnett: The important thing is to thank our scribe. I had a round of several weeks where I forgot to do that.

Drummond Reed: Thank you Dave!!!

Daniel Burnett: Thank you, Dave and Amy and Manu for stepping in.
… Thank you, Thank you, Thank you, wish you all a good 6 hours before our topic call.

No new actions