Meeting minutes
<KevinDean> https://
<swcurran> +present
<KevinDean> https://
Agenda Review. Introductions
Wip: simple agenda, we are goint to touch on TPAC, then talk about what happened on DID core and DID resolution
… any amendment to the agenda?
… Stephen, do you want to introduce yourself?
swcurran: consultant, working with the government. Been working with DIDs for a while.
… did:trust, did:web, did:tdw (for which I have a meeting just after this one)
… We will discuss how to integrate features of did:tdw into did:web.
<Zakim> manu, you wanted to note upcoming DID Standardization meeting next week (agenda+, sorry I'm late!)
swcurran: Just joined this group as an IE a week ago.
manu: I would like to add an agenda item about what Stephen just mentioned.
Wip: before we open this subject, other introductions?
TylerM: I'm with Digital Bazaar.
DID Method Standardization
manu: as Stephen mentioned, we are working on did:tdw.
… We can't standardize DID method in this WG, but we are having joint meetings with the CCG, DIF, and others, about DID method standardization.
… Anyone interested is welcome.
… We'll let everyone know when this happen. We want to have at least one meeting before TPAC, as we will be presenting the status of the work in a TPAC breakout session.
TPAC Preparation
Wip: firsrt thing: has any one signed up on the attendees sstylesheet (link above)?
… This is useful for us to know who will attend when, as well as dietary constraints.
<Wip> https://
Wip: Second: Dan has seen a slide deck that we will use for the two days (link above).
… In here you can find the agenda for the days (maybe subject to change).
… An email was sent to people who are expected to present: please put your material in the deck.
<Wip> https://
<Wip> https://
Wip: Finally, PA flagged to me that on Monday, some people might be interested in conflicting meetings (2 links above).
… Maybe we can have chat to have a sense of how much trouble this will be.
KevinDean: is it possible for non-participants to attend WG meetings during TPAC?
pchampin: yes, any TPAC participant can attend WG meetinds as observers.
manu: about the Digital Credential API meeting, it would be nice to be able to attend it. It is directly relevant to what we are doing.
… It would be good to attend that meeting and signaling DID as a possible part of DIgital Credential API.
… The Web payement work is also about Credentials, so it would be relevant, although the Web Payement group has taken a very different and specific route. IMO, less important but maybe interesting.
… All that being said, it is challenging if it takes time away from our WG meeting.
Wip: thanks for this input
DID Core Issue & PR Processing
manu: I'm going through our class 3 issues that are not ready to PR, then class 2 time permitting, and so on.
<manu> https://
w3c/did-core#836
manu: this input was received 3 years ago by Travis, from Microsoft
… they would like to see one foundation key representation.
… It means that we need to pick a single key representation, caused a lot of argument.
… It is now clear that people have expressed keys in various different formats.
… JWT, multikey (as used in did:key), ...
… At the California DMV, we have been using DID to express keys, starting with did:jwk, to actually express an X509 key.
… Our implementation experience has been pretty terrible. Most libraries on the marker don't check certificate chains.
… So they would report that a signature is fine, even if the chain is broken.
… All that said, the suggestion that we would have: yes, one key representation would be ideal, but the best we can do is to be explicit about what format is used.
ivan: I'm not an expert, but on a specification issue:
… not sure if we have a resolution to use the Controller Document, but it seems to me that this is the direction of the WG.
… The Controller Document mentions JWK and multikey as the two possible format, so we would inherit these two.
manu: I agree.
… Another thing that's maybe a little more controversial:
… I don't believe that we will ever have a unified key format.
<JoeAndrieu> +1 for key format flexibility
manu: SSH key formats have had their own format for 10 years. HEM and JWK exist and are widely used.
… Multikey is gaining adoption.
… The current language says "to improve interop, we are supporting only 2 formats."
… I'm questionning whether we should revise that language.
<KevinDean> +1 to removing AND acknowledging multiple key formats
Wip: I'm in favor of flexible key representation.
… Say I have my own key representation, how do I get it in the Controller Document?
markus_sabadello: some people say that standards are about making choices, so we should pick one format,
… but I don't think this is practical. We need an extensibility method.
… Some DID methods may have preference for certain key representation.
<Zakim> manu, you wanted to note "your key format" is supported via DID extension mechanism.
markus_sabadello: In the spec, we should give examples of the most common ones, but also explain how to extend.
manu: the spec already supports that through the extension mechanism.
… If you want to use PublicKeyHex or PublicKeyHem for example, the vocabulary terms exist. You could put them in your JSON-LD context.
… You can register your own properties, requires a JSON-LD context. We have always supported this.
Wip: we need some text explaining this.
<ivan> +1 to the drafty content of Manu...
manu: I can give it a try: saying "it would be great if we had a unified key format, but here are the ones that exist" + advising against adding more
KevinDean: I support the idea of flexibility and the ability to support additional key formats.
… For a minimum implementations, it is useful to know which subset are most likely to be supported.
DID Resolution PR and Issue Processing
<markus_sabadello> w3c/
w3c/did-resolution#49
markus_sabadello: this is a very old PR.
<manu> +1 to close
markus_sabadello: Just an editorial thing, no need to spend much time. Will marke it as "pending close"
w3c/did-resolution#88
markus_sabadello: this remove the part about dereferencing secondary resource. This is covered by the media-type.
JoeAndrieu: last time we talked about primary/secondary resources, I found it confusing.
… My understanding is that the primary resource of a DID URL or DID is the DID document.
… Secondary resources are the ones that the DID document tells you how to reach.
markus_sabadello: the other PR is a bit about that.
… In my view, the primary resource can be the DID document, but can be something else.
<Wip> w3c/
markus_sabadello: The primary resource is what you get when you retrieve the DID URL minus the fragment.
… The secondary resource is what you get when you include the fragment.
<Zakim> JoeAndrieu, you wanted to ask what else can it be? That's my concern.
markus_sabadello: That's what the URI RFC says.
JoeAndrieu: what other resource is it going to be?
… I think the primary resource of a DID is what you defef the DID. This would be the DID document, and this is consistent with the RFC.
markus_sabadello: if the DID URL does not have any additional path or query part, then I agree.
… But if you add query strings or parameters, the result might be different.
ivan: I was always bothered by this earlier.
… I understand what markus_sabadello says, up to the point where you talk about fragments.
… In my understanding, fragments talk about a part of the document, as in HTML.
<Zakim> manu, you wanted to ask about "what if it is not a JSON-LD document"?
manu: what you say is that fragment processing is up to the media-type, full stop.
… Is that what effectively what this PR is saying?
<Zakim> JoeAndrieu, you wanted to say my point is the DID URL refers to a secondary resource
JoeAndrieu: I understand what markus_sabadello is saying, but I don't agree.
<manu> I agree with Joe's more coherent framing, FWIW.
JoeAndrieu: Saying that a DID URL identifies a secondary resource of the DID document is confusing.
markus_sabadello: what you say is like saying: when I have an HTTP URL, you would first need to fetch the root of this URL before getting the document.
… in did:tdw, if you dereference the /whosis, you don't get the DID document.
ivan: I think it would be better to separate two things:
… 1 the path and query string, for which I agree with markus_sabadello, it may deference to something different that the "root" URL
… 2 fragments, for which the client needs to do something with the whole content
<KevinDean> https://
<Zakim> JoeAndrieu, you wanted to yes. we DO need to get the DID Document
ivan: those are different things, we need to treat them separately
JoeAndrieu: markus_sabadello, we are talking past each other
… to use the /whois URL, you need the DID document. This is different from how HTTP URIs work.
<Zakim> pchampin, you wanted to talk about "fragment"
pchampin: I disagree with Ivan, looked up RFC for URIs. Fragment identifiers don't identify "fragments". The spec talks about secondary resources as the things that are identified by fragments, not bound to parts of whole representation ... and can be entirely different e.g., used in RDF to refer to things "outside" the document.
<swcurran0> +1
pchampin: With respect to what Joe said, not an expert in DID Resolution, what you're saying is you need DID Document, that makes the DID DOcument "primary", but not in the sense of the RFC. The second one is "primary", agree with markus, maybe we need another term to not clash w/ RFC terminology.
KevinDean: link above to the definition of fragments / secondary document
… we must be careful when we refer to terminology.
Wip: we need to move forward.
<bigbluehat> From RFC3985#section-3.5
<bigbluehat> > The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
<Wip> See issues here - https://
markus_sabadello: the section about dereferencing tries to stay really close to RFC3986
… the primary resource is what you get when you dereference the URL with the path and query string, but without the fragment.
… again, see the example of /whois.
<swcurran0> +1 to Markus that the primary resource may not be a DIDDoc -- significantly opens up the power of DID URLs
<Zakim> JoeAndrieu, you wanted to say it seems like we won't reach consensus on the meaning of primary and secondary resource. We should find other language.
JoeAndrieu: we probably are not going to get consensus on "primary/secondary document"
… we need to coin new terms and be clear about what we mean by that.
<swcurran0> -1 to new language.
manu: if we use new language, it may confuse people even more. We will need to map it to existing language, explain why we came up with our own...
That was clear, markus_sabadello
markus_sabadello: if you look at the resolution spec, it has 3 steps: 1. resolve the DID, 2. resolve the primary resource, 3. resolve the secondary resource
<markus_sabadello> https://
JoeAndrieu: in 4.3 the first step is "getting the primary resource"; may be that requires a re-indexing of the section
Wip: I'll try to read that section; maybe others can review it
… markus_sabadello, which of the two PRs we mentioned is the best place to continue the discussion?
markus_sabadello: both are relevant, 88 and 89
<markus_sabadello> 4.3 says: "it consists of the following steps: Resolving the DID, dereferencing the primary resource, and dereferencing the secondary resource "
<swcurran0> About the did:tdw meeting -- agenda with Zoom link is: https://
Wip: markus_sabadello marked a number of issues and pending_close, chime in if that concerns you