Meeting minutes
Agenda Review
Wip: fairly straightforward on agenda today... most of time on DID Resolution, any amendments to agenda?
No additions
Special Topic Call Announcement
Wip: We will have a special topic call next Wednesday at 7am PT, topic is about controller document.
<decentralgabe> https://
decentralgabe: I have updated the special topic call agenda at the link above
decentralgabe: That does overlap w/ VCWG, issues and PRs to discuss this, impactful for this group, we should discuss as well.
Wip: Any other comments on this?
DID Core Issue Processing
manu: an update. I'm ready to make all of the changes to the DID Methods and DID Extensions documents
… before I started moving things around, I wanted to confirm that was fine with everyone
… the other item. pchampin I need help making a new repo
… and then we'll need to make redirects in TR space to the new publications, etc.
… I just wanted to confirm here that there were no objections to this plan
… to be clear: what I'm intending to do...
… take the current DID spec registries repo and clone it with all of it's history and split it into two things
… did-methods which will only contain methods
… the other will be did-extensions which will be everything else
… we'll update the registration processes in each to be specific to each of these new documents
… That's the first iteration
… we can then begin doing PRs, minor modifications, etc.
… pchampin, would you be able to help next week?
… the repo cloning is the main thing
Wip: so, are we getting two repos? or one repo with two things in it?
manu: oh. you're right. It's just on repo
… so pchampin , I don't need help after all
… we'll use subdirectories
… but we will still need redirects
<Zakim> manu, you wanted to cover DID Core.
manu: I need to go back and confirm things in the resolution
<Zakim> Wip, you wanted to clarify this is all under one repo
manu: we did discuss this...so I'll go back and confirm details, but I did want to double confirm this plan was fine.
pchampin: I just wanted to point out that having two specs in one repo will make things like PR preview hard
… was that considered when the single repo plan was made?
manu: I thought PR preview handled multiple specs in one repo
pchampin: we should check
manu: the HTML5 spec has subdirectories, so I think it should work, but we should check
Wip: issues are next
w3c/did-core#811
manu: for time, I'm going to tackle highest class issues first
… 811 has to do with adding new verification material to use references with JWK
… this would be a class 4 change
… it needs a new term, a new context
… it's not clear which group should do this, though
… as the Controller Document is at the VC WG
… and they should be involved
… this issue has been around since 2021
… and I've not heard that it's caused any harm or prevented use of DID or the upcoming Controller Document spec
… there is some question about whether a new property is actually needed or if a service endpoint would be sufficient
<Zakim> JoeAndrieu, you wanted to ask if the statement about the only supported verification methods is valid
manu: given this is a class 4 change with little discussion, we may want to reconsider this approach
JoeAndrieu: It feels like a misunderstanding of extensibility
… this can be supported through existing extension options
manu: that's correct, anyone could add this feature. This may be a direct ask for us to make it though
… since it's a class 4 change with little demand, so maybe the response is to suggest they make an extension
… and then if it gets broadly adopted, we an reconsider it here
… any objections to that approach?
JoeAndrieu: I support that approach
manu: so, should we annotate this in some way?
… it's difficult for me to summarize all this
pchampin: I have a script we can use to connect the PRs to the minutes related to the issue
… I'll test this today on the main repo, and then later we'll have an IRC bot do this for us
… it's using the minutes, so once those are generated, we can have the bot make these connections
w3c/did-core#859
manu: this is about whether we publish a v1.1 context
… do we want to make a new v1.1 context with some of the new Controller Document features
… so people can start using terms from that doc automatically
… we could make this new context, which would be up-to-date--solving our limbo status of the last two years
… so, do we want to do this? it should be a class 3 change, since using the new context would be optional
… we'd have to be careful of the text we use here
… that using the new context is optional
… but that said, we could also decide not to and depend on the extensibility mechanisms
… and then only add these when we get to a v2.0
dmitriz: so, this feels strictly binary
… if we add any new fields for JWKs or something else, then we should do a new context
… and it might be a good excuse to add convenience terms
… so I think it's a good idea
<Zakim> Wip, you wanted to ask about existing systems
JoeAndrieu: I agree. I think we should be open to changing it if/when we create new terms
Wip: I do think this is sensible
… existing systems would have to update though
<Zakim> manu, you wanted to note we do have some new terms
dmitriz: only if we add new terms
manu: anyone using v1.0 can keep using that and we wouldn't prevent that
… we can say in the spec, that you can pick either one based on if you want these extra terms this way rather than via using extension contexts
… JoeAndrieu you said we may not currently have new terms, but I think we do
… one is `JSONWebKey2020` would loose it's date and just be `JSONWebKey`
… other similar changes that would just make things look cleaner
… there are at least a couple
Wip: any final comments?
DID Resolution Issue Processing
Wip: k, markus_sabadello , let's talk resolution and processing
<Wip> This PR has been merged w3c/
markus_sabadello: I merged PR 84, all content related to DID Resolution in DID Core should be in DID Resolution specification.
markus_sabadello: I started to look through open issues, didn't quite get through all of them, but started going through issues and tried to identify ones that are obsolete, added comments to them, labeled issues a bit, work in progress, in middle of navigating through open issues.
markus_sabadello: I created four issues about a month ago, when we started a WG, intention to gather some high level feedback on scope/structure of spec.
markus_sabadello: Those were issues w3c/
markus_sabadello: Last week discussion happened there, didn't see any major concerns or any major disagreements with having those topics in DID Resolution. The idea was to get an initial feeling on working on the right things. No opinion against that. I wonder if it would be appropriate to close those high-level issues and start working on details.
markus_sabadello: What I'd like to do on future calls is go through individual sections on specification one by one and some of it may be new to the group. Not everyone has had a chance to look through spec.
markus_sabadello: I could also give an overview now, might be valuable to look at current structure of spec to do an intro on scope and topics are in general.
Wip: I think that would be valuable. Issues 81-83, might be good to get through them, what are details?
markus_sabadello: Ok, let's do that. I'll walk through each section.
markus_sabadello: We could look at individual issues, categorized/commented on them, helpful to stay at high level for this call and then do an intro of the sections to get some feedback.
Markus shares his screen.
markus_sabadello: One of the main topics/sections in beginning of spec is the algorithms. DID Resolution and DID URL Dereferencing. This replaces, to some extent, what was in DID Core.
markus_sabadello: We moved these items from DID Core to DID Resolution. Defines inputs and outputs of DID Resolution and metadata and then defines algorithm.
markus_sabadello: If inputs are of a certain nature, a resolver performs the following steps and results should be as follows.
markus_sabadello: This all should be testable.
… This is also done for dereferencing.
… Dereferencing has inputs, outputs, and algorithm. Algorithm has two parts, dereferencing primary and the secondary resource... secondary is around fragment processing. Here the algorithm tries to describe how to handle certain parameters in DID Core. Service parameter, relative ref, versionId, versionTime, all of which is covered in DID URL Dereferencing, but maintains a lot of freedom for extensibility and innovation in DID URLs in different
communities. Proposing a presentation for TPAC, how much of DID URLs and Dereferencing should be standardized?
markus_sabadello: one reason why I made this a separate subsection
manu: Have you put much thought into when media type fragment processing rules come into play?
markus_sabadello: is that it's also interesting to resolver architectures
markus_sabadello: it could use a combination of remote and local dereferencing, which is why I divided it into sections
markus_sabadello: We do talk about that, where primary resource is dereferences by primary architectural components, remote resolver service, resolved locally, with web browsers, to explain this in architecture section, that's why it's divided in the algorithm section. In general, I agree completely w/ what you said wrt. media type, interesting edge use case that you described... in some cases, for example
markus_sabadello: We have service and relative ref, and have primary resource, and result of that is service endpoint URL, then result has a service endpoint with a fragment, what happens with that fragment?
markus_sabadello: I don't know the actual answer at the moment, right now, it says "fragment is inherited" and put at end of service endpoint URL. There are similar questions in HTTP URLs and redirects. If you open a URL and it redirects w/ a 302, does browser preserve fragment on redirected URL?
<Zakim> JoeAndrieu, you wanted to mention introducing a distinction between with and without the trailing / in path part.
markus_sabadello: So, that kind of thing... don't have solution for that, but we should cover that here.
JoeAndrieu: If the DID URL/URI is dereferenceable, the fragment has to apply to resource that's dereferenced.
JoeAndrieu: However, if there isn't a path part, fragment applies to DID Document, that distinction might help us through this.
markus_sabadello: Yes, I agree. If input URL doesn't have query/path, then primary resource is DID Document, secondary resource is fragment according to media type.
markus_sabadello: There is a step where it defines how to extract a JSON-LD object by matching the id property.
Wip: If we need a tracking issue for this, we should raise it.
<Zakim> JoeAndrieu, you wanted to say maybe clarify primary resources is did document and use that term
markus_sabadello: I'll add that myself or someone else to issue 80 or create a new one.
JoeAndrieu: A possible shift in language - agree that primary and secondary resource links us to RFC 3986... once we explain primary/secondary link to ... then we should talk about DID Document ... we shouldn't talk about primary resource anymore, let's talk about DID Document.
https://
<JoeAndrieu> +1 I like that.
bigbluehat: In web annotation WG, we used the concept of a "specific resource" in place of a "secondary resource". You've gotten the representation back, from HTTP, then you're focusing in on that. I don't know if that's helpful, but it worked for us after wordsmithing for over a year.
markus_sabadello: Dereferencing a DID URL can return a DID Document, but it can also return any other type of content. If anyone sees it differently, we shoul ddiscuss that, there are examples in community of implementers where you have a DID with a path, have an object, resource, representation of aresource, media type... schema or PDF file, and as Manu said, fragment is independent of that.
<Zakim> JoeAndrieu, you wanted to talk about returning a did document
markus_sabadello: If DID URL identifies a DID Document, or PDF file, then fragment always works the same way, Not sure if we have to distinguish that on the level of the fragment processing. However, I see what you're saying Joe, we could say more prominently that if you're working w/ the DID Document, we use that term and not primary resource.
markus_sabadello: Let us know about any high-level feedback on structure; we can continue w/ diving into details later, but PR is there.
markus_sabadello: After algorithms, there is a section on metadata structure, copied from DID Core, how Metadata works.
<Zakim> JoeAndrieu, you wanted to ask how do we define metadata?
markus_sabadello: Then there is a big section about architectures, remote resolvers vs. local resolvers vs. trust in resolvers and verifiability of results and signatures and proofs. All of that should go into that section.
JoeAndrieu: Do we have a clear definition of metadata? For example, we talk about versionId differently... it's in DID Document vs. Metadata.
markus_sabadello: We discussed that in the F2F meeting and the question we asked was: Are we talking about data about the subject identified by the DID, or data about DID and DID Document itself. Created property, if we had that property, when was subject created, identified by the DID, or when was DID and DID Document created?
markus_sabadello: That's the question we're asking... is it in the DID Document or not?
JoeAndrieu: I don't think I like that definition... what's the nature of the statements in the DID Document and what are they about. If the statements are about the subject, then we're overlapping w/ VC w/o the protections
markus_sabadello: This sounds like a bigger issue, maybe we need a separate issue for it.
manu: just to push back a tiny bit
… I'm concerned about over specialiazing too early
… if we use the ID and make statements about that subject, that is similar to VCs
… no contest there...agreed
… however, there are other things that can secure that payload
… I think this is a side effect of using a generic data model
… restricting what goes in to a DID document is a good idea
… but I fear painting ourselves into a corner
… and we may put things out of scope unnecessarily
… so I get a little concerned about creating a differing model for DIDs from VCs when the distinction may not be necessary
markus_sabadello: Ok, so we talked about metadata, architectures, resolution result, dereferencing results, and errors.
markus_sabadello: We can debate error codes or if some are missing or some are considered extensions.
manu: we're starting to use the ProblemDetails object from the IETF in some of the VC specs
… I wonder if we might consider that here as well
… have you seen any of that work?
… curious to hear your thoughts on that approach
markus_sabadello: I'm aware of it and agree it could be a good fit here
markus_sabadello: Yes, aware of ProblemDetails object and agree that it could be a good fit here.
Wip: ok, good discussion, thanks for the overview Markus. Next step is to dive into the spec, feedback on issues getting into details, actionable changes.
Wip: Next time, unless anyone has any issue... we'll spend time doing issue processing on DID Resolution.
Wip: Thanks everyone, have a great weekend, see you next week.