Meeting minutes
Agenda Review
Wip: Agenda review -- announcement about calls, DID Extensions TR space, DID Core Media types, then over to DID Resolution issue/PR processing. Anything else to add?
DIDWG Call Cancelled 31st of October
Wip: Announcement, we're canceling October 31st meeting due to IIW.
Wip: Dan is stepping back from being a Chair (which was planned), he won't be showing up to meetings anymore.
DID Extensions TR Space
Wip: DID Extensions and TR space, hoping to hand this over to PA for an overview of the problem and how we might solve them.
pchampin: The new document has a hierarchical structure, DID extensions, which points to other documents in subfolders on Github repository, after checking w/ sysadmins, we can't do that on TR (URL space for Technical Reports), every document is at top-level. What is currently .../TR/did-extensions/methods/ will now become .../TR/did-extensions-methods/
<danpape> +present
pchampin: This requires a change in the Editor's change and then I will make a request for publication of those things, since they are "brand new", before we can automate their publication, we need to seed this process by normal request.
manu: last week we had a resolution to do just that
pchampin: Yes, saw the resolution, before I can take an action, I need the repos to reflect this.
manu: I can do it. Which repository do you mean?
ivan: Orginally queued to something else, where is the resolution?
ivan: Several documents in same repo, for historical reasons we did this for epub, one repo with 3 TRs and 10 notes all in same repo. You have to generate as many echidna files as there are documents that are automated and it works. You can copy how epub did their thing.
ivan: One thing that was not done is that we have to make a resolution on using Echidna, we can make that a generic resolution.
Wip: We should do that today?
manu: we already did this resolution for Echidna
<ivan> for VC:
ivan: it lists an explicit set of documents, which might come back a bite us later
Wip: We think we've done it for all documents we have.
ivan: Remember that we might change names, etc.
pchampin: I just noticed that my page for listing resolutions is broken... links pasted do not work.
Wip: Let's move on unless anyone else feels differently?
pchampin: The links need to be changed, the structure needs to be changed.
ivan: this is required because echidna can not publish the documents in a hierarchy
manu: I can still this work for echidna without changing the structure of the repository
ivan: this would make your life harder
manu: actually, changing the structure would be even harder
DID Core Media Types
w3c/did-core#863
manu: during TPAC, the TAG suggested to add some text in the VC documents about JSON-LD,
… but that also applies to the DID WG.
… The text is to explain (even more) clearly that downloading JSON-LD contexts from the web is not necessary for complying with the standard.
… And that processing a VC or DID document as JSON is equivalent to processing it as JSON-LD.
… The proposal was to add some text saying "any difference in the behaviour between JSON and JSON-LD would be a bug of this spec"
… We have some text to this effect in VC.
… In the Controller Document spec, we got to a point where there is no difference between JSON and JSON-LD processing.
… As a side effect, we can have a single media-type.
<ivan> VC's version on the JSON(-LD) that Manu was talking about:
manu: We never picked a media-type because of 5-year long debate at IETF about multiple suffixes in media-types.
… The proposal to this group is to do the same for did: would people be happy with a media-type like application/did ?
… We haven't heard any pushback so far. Should be take a resolution?
markus_sabadello: A CBOR representation would have a different media type, but there would be no difference between JSON and JSON-LD?
manu: correct
markus_sabadello: I think that would be fine, sounds like a good idea, one thing I'm wondering, separate media type for DID Resolution result.
markus_sabadello: Separate media type for that, I think that's fine, sounds like a separate question we can discuss separately, but don't think there would be any implications/problems, sounds good.
manu: I agree, we should have a separate media-type for DID Resolution results.
… Another thing we did in VC is tell people "use the most accurate media-type when you serve these documents".
… Many people get media-types wrong, so often that people are encouraged to not rely on media-types.
… For a JSON(-LD) prepresentation, this would be application/did ; for a CBOR representation, this would be something like application/did+cbor .
… Serving a DID document as application/ld+json or application/json is not wrong, but not optimal.
… A text to this effect has reached consensus in the VC WG, I will do something similar for DID.
… Developers should be ready to deal with lower fidelity media-types.
Wip: Quick comment, this text is in the controller document, will we rely on that? Controller document has its own media type?
manu: good question. I think the Controller Document will have its own media-type.
… We don't want to duplicate content. I try to get a sense of what the group wants.
… We fist need a decision on the DID document media-type, then we can discuss the rest.
Wip: Any comments on the draft proposals?
pchampin: Without being too pedantic, the spec makes a clear disctinction between a DID and a DID Document, application/did might be a bit confusing since a DID is an identifier?
manu: I take your point. I'm wondering if it matters all that much?
<ivan> +1 manu
manu: I don't think we would ever serve a pure DID with a media-type.
… It feels nicer to have a short compact media-type.
PROPOSAL: The media type for the JSON and JSON-LD expression of a DID Document will be application/did.
<dmitriz> +1
<TallTed> +1
<Wip> +1
<manu> +1
<ivan> +1
<markus_sabadello> +1
<pchampin> +0.5
<JennieM> +1
<bigbluehat> +1
RESOLUTION: The media type for the JSON and JSON-LD expression of a DID Document will be application/did.
PROPOSAL: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications.
<manu> +1
<Wip> +1
<dmitriz> +1
<TallTed> +1
<JennieM> +1
<ivan> +1
<JoeAndrieu> +1
<markus_sabadello> +1
<pchampin> +1
RESOLUTION: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications.
DID Resolution Issue/PR Processing
w3c/did-resolution#89
markus_sabadello: This is about primary and secondary resource, come up with better names, we mentioned that Joe and myself would try to propose better terminology, hasn't happened yet. Marked it as "do not merge", we don't want to use "primary/secondary" resource terminology. We will just keep this open.
manu: I thought we discussed this previously?
markus_sabadello: We did discuss it on the last call and you're right, but we need a better term, we need a term for ... what is the term when you dereference a URL... what's that thing, not a primary resource... we could just call it "first part dereferencing" and then "fragment dereferencing"... what is the thing when you dereference a DID URL w/o path and fragment?
markus_sabadello: Just a reminder for people to think more about this.
Wip: Yes, Markus and Joe are going to propose something.
w3c/did-resolution#88
markus_sabadello: I can merge this, right?
Wip: Yes.
w3c/did-resolution#23
markus_sabadello: I'll close this at end of meeting, marked it pending close last week, no further comment/objection, closing at end of this call.
<markus_sabadello> https://
markus_sabadello: There are a number of older issues, one with the latest input was 22
w3c/did-resolution#22
markus_sabadello: This is about signing a DID Document, feel like it's covered by DID Core... section on signing DID Documents.
markus_sabadello: I asked them for further input through CCG, don't really know what it's asking from DID Resolution.
manu: I don't remember anything about signing. Where is it?
… Found it. There is a note.
https://
manu: I agree with you. I don't know what's expected from Resolution for this.
… A future DID methods WG would look into that.
… Some canadian people are working on multi-factor authentication.
… We need to put something in DID Resolution, but something generic, as this is very method specific.
Wip: I put myself on the queue to respond to something you said, Manu -- some DID Methods might be signing their DID Documents, but it's only for their DID Method resolution processes which require those signatures. DID Resolution could probably only say "if there are signatures you should verify them".
markus_sabadello: Then add a comment to the issue to what we just discussed and leave it open, at some point DID Resolution could do something w/ signed DID Documents.
w3c/did-resolution#35
markus_sabadello: I opened this a five years ago, there was an issue in the DID spec about potential privacy concerns associated with data in the DID Document itself, like service endpoints, idea was that if you include service endpoints, endpoints could be sensitive or correlatable, idea was to introduce a proxy service type where you could look up what is normally in the DID Document but use a remote service for looking up parts of the DID Document to not
… include correlatable information in the DID DOcument itself. Wonder what we should do with this?
markus_sabadello: We can mark this an enhancement for now... in five years, no one has worked on this, or had a real life need for this.
manu: Dave Longley wrote something about this, I don't think we have anyone working on that right now.
… We have a number of DIDs floating on the Web, and people use those DIDs to discover how to interact with the DID controller.
… But this is not how things operate now; DID controllers identify with their DID, then use some web service to start an interaction.
markus_sabadello: I agree, if anyone ever specifies/implements this, it's a service type so just like defining a different service type like DIDComm or OpenID, so probably be in a separate spec anyway and registered as an extension. Doesn't feel like something that needs to be in DID Resolution itself.
Wip: How do we process this issue? "lacks interest"?
markus_sabadello: I opened this, could add comment -- this could be useful as an extension, but doesn't need to be in DID Resolution.
Wip: That's all we have time for today, any particular issues that could deal with some attention next week?
markus_sabadello: Not sure right now, I'll look.