14:52:16 <RRSAgent> RRSAgent has joined #did
14:52:20 <RRSAgent> logging to https://www.w3.org/2024/08/29-did-irc
14:52:26 <Wip> rrsagent, draft minutes
14:52:28 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html Wip
14:52:36 <Wip> rrsagent, make logs public
14:52:45 <Wip> Meeting: Decentralized Identifier Working Group
14:52:56 <Wip> Chair: Will Abramson
14:54:28 <Wip> present+
14:57:53 <TallTed> TallTed has joined #did
14:59:27 <decentralgabe> decentralgabe has joined #did
15:01:07 <decentralgabe> present+
15:02:20 <markus_sabadello> markus_sabadello has joined #did
15:02:30 <pchampin> present+
15:02:31 <manu> present+
15:02:41 <bigbluehat> bigbluehat has joined #did
15:03:04 <markus_sabadello> present+
15:03:51 <JoeAndrieu> JoeAndrieu has joined #did
15:03:52 <dmitriz> present+
15:04:27 <manu> scribe+
15:04:28 <bigbluehat> present+
15:04:44 <bigbluehat> scribe+
15:04:54 <Wip> Topic: Agenda Review
15:05:20 <manu> Wip: fairly straightforward on agenda today... most of time on DID Resolution, any amendments to agenda?
15:05:28 <manu> No additions
15:05:37 <Wip> Topic: Special Topic Call Announcement
15:05:56 <manu> Wip: We will have a special topic call next Wednesday at 7am PT, topic is about controller document.
15:06:04 <decentralgabe> https://www.w3.org/events/meetings/7fcaaebc-61ac-4f87-921d-accdb271496a/20240904T100000/
15:06:08 <manu> decentralgabe: I have updated the special topic call agenda at the link above
15:06:28 <manu> decentralgabe: That does overlap w/ VCWG, issues and PRs to discuss this, impactful for this group, we should discuss as well.
15:06:33 <manu> Wip: Any other comments on this?
15:06:47 <manu> q+ to cover DID Core.
15:06:51 <Wip> Topic: DID Core Issue Processing
15:07:01 <TallTed> present+
15:07:35 <bigbluehat> manu: an update. I'm ready to make all of the changes to the DID Methods and DID Extensions documents
15:07:48 <bigbluehat> ... before I started moving things around, I wanted to confirm that was fine with everyone
15:07:50 <JennieM> JennieM has joined #did
15:07:58 <bigbluehat> ... the other item. pchampin I need help making a new repo
15:07:58 <JennieM> present+
15:08:14 <bigbluehat> ... and then we'll need to make redirects in TR space to the new publications, etc.
15:08:27 <bigbluehat> ... I just wanted to confirm here that there were no objections to this plan
15:08:40 <bigbluehat> ... to be clear: what I'm intending to do...
15:08:59 <bigbluehat> ... take the current DID spec registries repo and clone it with all of it's history and split it into two things
15:09:11 <bigbluehat> ... did-methods which will only contain methods
15:09:26 <bigbluehat> ... the other will be did-extensions which will be everything else
15:09:45 <Smccown> Smccown has joined #did
15:09:49 <bigbluehat> ... we'll update the registration processes in each to be specific to each of these new documents
15:09:58 <bigbluehat> ... That's the first iteration
15:10:09 <bigbluehat> ... we can then begin doing PRs, minor modifications, etc.
15:10:20 <bigbluehat> ... pchampin, would you be able to help next week?
15:10:27 <bigbluehat> ... the repo cloning is the main thing
15:10:27 <Wip> q+ to clarify this is all under one repo
15:10:52 <bigbluehat> Wip: so, are we getting two repos? or one repo with two things in it?
15:11:02 <bigbluehat> manu: oh. you're right. It's just on repo
15:11:11 <bigbluehat> ... so pchampin , I don't need help after all
15:11:17 <bigbluehat> ... we'll use subdirectories
15:11:21 <pchampin> q+
15:11:24 <bigbluehat> ... but we will still need redirects
15:11:34 <Wip> ack manu
15:11:34 <Zakim> manu, you wanted to cover DID Core.
15:11:37 <bigbluehat> ... I need to go back and confirm things in the resolution
15:11:37 <Wip> ack Wip
15:11:37 <Zakim> Wip, you wanted to clarify this is all under one repo
15:11:59 <Wip> ack pchampin
15:12:06 <bigbluehat> ... we did discuss this...so I'll go back and confirm details, but I did want to double confirm this plan was fine.
15:12:07 <Smccown> Smccown has joined #did
15:12:22 <Smccown> present+
15:12:23 <bigbluehat> pchampin: I just wanted to point out that having two specs in one repo will make things like PR preview hard
15:12:39 <bigbluehat> ... was that considered when the single repo plan was made?
15:12:52 <bigbluehat> manu: I thought PR preview handled multiple specs in one repo
15:12:56 <bigbluehat> pchampin: we should check
15:13:22 <bigbluehat> manu: the HTML5 spec has subdirectories, so I think it should work, but we should check
15:13:44 <bigbluehat> Wip: issues are next
15:13:55 <manu> subtopic: https://github.com/w3c/did-core/issues/811
15:13:59 <bigbluehat> manu: for time, I'm going to tackle highest class issues first
15:14:15 <bigbluehat> ... 811 has to do with adding new verification material to use references with JWK
15:14:21 <bigbluehat> ... this would be a class 4 change
15:14:33 <bigbluehat> ... it needs a new term, a new context
15:14:46 <bigbluehat> ... it's not clear which group should do this, though
15:14:59 <bigbluehat> ... as the Controller Document is at the VC WG
15:15:04 <bigbluehat> ... and they should be involved
15:15:20 <bigbluehat> ... this issue has been around since 2021
15:15:20 <Smccown> Smccown has joined #did
15:15:45 <JoeAndrieu> q+ to ask if the statement about the only supported verification methods is valid
15:15:45 <bigbluehat> ... and I've not heard that it's caused any harm or prevented use of DID or the upcoming Controller Document spec
15:16:04 <pchampin> RRSAgent, draft minutes
15:16:05 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
15:16:12 <bigbluehat> ... there is some question about whether a new property is actually needed or if a service endpoint would be sufficient
15:16:16 <Wip> ack JoeAndrieu
15:16:16 <Zakim> JoeAndrieu, you wanted to ask if the statement about the only supported verification methods is valid
15:16:27 <bigbluehat> ... given this is a class 4 change with little discussion, we may want to reconsider this approach
15:16:41 <bigbluehat> JoeAndrieu: It feels like a misunderstanding of extensibility
15:16:47 <manu> q+
15:16:52 <Wip> ack manu
15:16:55 <bigbluehat> ... this can be supported through existing extension options
15:17:12 <bigbluehat> manu: that's correct, anyone could add this feature. This may be a direct ask for us to make it though
15:17:34 <bigbluehat> ... since it's a class 4 change with little demand, so maybe the response is to suggest they make an extension
15:17:47 <bigbluehat> ... and then if it gets broadly adopted, we an reconsider it here
15:17:54 <bigbluehat> ... any objections to that approach?
15:18:07 <manu> q+
15:18:11 <bigbluehat> JoeAndrieu: I support that approach
15:18:13 <Wip> ack manu
15:18:36 <pchampin> q+
15:18:50 <bigbluehat> manu: so, should we annotate this in some way?
15:18:56 <Wip> ack pchampin
15:19:04 <bigbluehat> ... it's difficult for me to summarize all this
15:19:25 <bigbluehat> pchampin: I have a script we can use to connect the PRs to the minutes related to the issue
15:19:43 <bigbluehat> ... I'll test this today on the main repo, and then later we'll have an IRC bot do this for us
15:20:06 <bigbluehat> ... it's using the minutes, so once those are generated, we can have the bot make these connections
15:20:38 <manu> subtopic: https://github.com/w3c/did-core/issues/859
15:20:58 <bigbluehat> manu: this is about whether we publish a v1.1 context
15:21:10 <dmitriz> q+
15:21:13 <bigbluehat> ... do we want to make a new v1.1 context with some of the new Controller Document features
15:21:25 <bigbluehat> ... so people can start using terms from that doc automatically
15:21:46 <bigbluehat> ... we could make this new context, which would be up-to-date--solving our limbo status of the last two years
15:22:03 <bigbluehat> ... so, do we want to do this? it should be a class 3 change, since using the new context would be optional
15:22:14 <bigbluehat> ... we'd have to be careful of the text we use here
15:22:21 <bigbluehat> ... that using the new context is optional
15:22:39 <bigbluehat> ... but that said, we could also decide not to and depend on the extensibility mechanisms
15:22:44 <Wip> ack dmitriz
15:22:47 <bigbluehat> ... and then only add these when we get to a v2.0
15:22:56 <bigbluehat> dmitriz: so, this feels strictly binary
15:23:18 <JoeAndrieu> q+
15:23:18 <bigbluehat> ... if we add any new fields for JWKs or something else, then we should do a new context
15:23:33 <Wip> ack JoeAndrieu
15:23:38 <bigbluehat> ... and it might be a good excuse to add convenience terms
15:23:43 <bigbluehat> ... so I think it's a good idea
15:23:52 <Wip> q+ to ask about existing systems
15:23:54 <manu> q+ to note we do have some new terms
15:23:56 <Wip> ack Wip
15:23:56 <Zakim> Wip, you wanted to ask about existing systems
15:23:58 <bigbluehat> JoeAndrieu: I agree. I think we should be open to changing it if/when we create new terms
15:24:06 <bigbluehat> Wip: I do think this is sensible
15:24:16 <bigbluehat> ... existing systems would have to update though
15:24:20 <Wip> ack manu
15:24:20 <Zakim> manu, you wanted to note we do have some new terms
15:24:25 <bigbluehat> dmitriz: only if we add new terms
15:24:45 <bigbluehat> manu: anyone using v1.0 can keep using that and we wouldn't prevent that
15:25:23 <bigbluehat> ... 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
15:25:42 <bigbluehat> ... JoeAndrieu you said we may not currently have new terms, but I think we do
15:26:03 <bigbluehat> ... one is `JSONWebKey2020` would loose it's date and just be `JSONWebKey`
15:26:13 <bigbluehat> ... other similar changes that would just make things look cleaner
15:26:23 <bigbluehat> ... there are at least a couple
15:26:29 <bigbluehat> Wip: any final comments?
15:26:37 <Wip> Topic: DID Resolution Issue Processing
15:26:47 <bigbluehat> ... k, markus_sabadello , let's talk resolution and processing
15:27:00 <pchampin> RRSAgent, draft minutes
15:27:02 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
15:27:39 <Wip> This PR has been merged https://github.com/w3c/did-resolution/pull/84
15:27:39 <manu> markus_sabadello: I merged PR 84, all content related to DID Resolution in DID Core should be in DID Resolution specification.
15:28:16 <manu> 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.
15:28:41 <manu> 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.
15:28:49 <manu> markus_sabadello: Those were issues 80, 81, 82, and 83.
15:29:41 <manu> 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.
15:30:07 <manu> 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.
15:30:30 <manu> 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.
15:30:46 <manu> Wip: I think that would be valuable. Issues 81-83, might be good to get through them, what are details?
15:31:04 <manu> markus_sabadello: Ok, let's do that. I'll walk through each section.
15:31:39 <manu> 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.
15:31:49 <manu> Markus shares his screen.
15:32:30 <manu> 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.
15:32:58 <manu> 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.
15:33:13 <manu> markus_sabadello: If inputs are of a certain nature, a resolver performs the following steps and results should be as follows.
15:33:18 <manu> markus_sabadello: This all should be testable.
15:33:51 <manu> ... This is also done for dereferencing.
15:35:42 <manu> ... 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
15:35:42 <manu> communities. Proposing a presentation for TPAC, how much of DID URLs and Dereferencing should be standardized?
15:35:44 <manu> q+
15:35:57 <Wip> ack manu
15:38:29 <bigbluehat> markus_sabadello: one reason why I made this a separate subsection
15:38:32 <manu> manu: Have you put much thought into when media type fragment processing rules come into play?
15:38:40 <bigbluehat> ... is that it's also interesting to resolver architectures
15:38:59 <JoeAndrieu> q+ to mention introducing a distinction between with and without the trailing / in path part.
15:39:24 <bigbluehat> markus_sabadello: it could use a combination of remote and local dereferencing, which is why I divided it into sections
15:39:38 <manu> 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
15:40:04 <manu> 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?
15:40:48 <manu> 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?
15:41:02 <Wip> ack JoeAndrieu
15:41:02 <Zakim> JoeAndrieu, you wanted to mention introducing a distinction between with and without the trailing / in path part.
15:41:02 <manu> markus_sabadello: So, that kind of thing... don't have solution for that, but we should cover that here.
15:41:31 <manu> JoeAndrieu: If the DID URL/URI is dereferenceable, the fragment has to apply to resource that's dereferenced.
15:41:48 <manu> JoeAndrieu: However, if there isn't a path part, fragment applies to DID Document, that distinction might help us through this.
15:42:26 <manu> 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.
15:42:47 <manu> markus_sabadello: There is a step where it defines how to extract a JSON-LD object by matching the id property.
15:43:07 <JoeAndrieu> q+ to say maybe clarify primary resources is did document and use that term
15:43:10 <manu> Wip: If we need a tracking issue for this, we should raise it.
15:43:20 <Wip> ack JoeAndrieu
15:43:20 <Zakim> JoeAndrieu, you wanted to say maybe clarify primary resources is did document and use that term
15:43:21 <manu> markus_sabadello: I'll add that myself or someone else to issue 80 or create a new one.
15:44:40 <manu> 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.
15:44:48 <bigbluehat> q+
15:44:53 <Wip> ack bigbluehat
15:44:59 <bigbluehat> https://www.w3.org/TR/annotation-model/#specific-resources
15:45:12 <JoeAndrieu> +1 I like that.
15:45:31 <manu> 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.
15:45:51 <JennieM> JennieM has joined #did
15:46:08 <JoeAndrieu> q+ to talk about returning a did document
15:46:31 <manu> 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.
15:47:10 <Wip> ack JoeAndrieu
15:47:10 <Zakim> JoeAndrieu, you wanted to talk about returning a did document
15:47:15 <manu> 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.
15:48:13 <manu> markus_sabadello: Let us know about any high-level feedback on structure; we can continue w/ diving into details later, but PR is there.
15:48:21 <pchampin> RRSAgent, draft minutes
15:48:23 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
15:48:38 <manu> markus_sabadello: After algorithms, there is a section on metadata structure, copied from DID Core, how Metadata works.
15:48:56 <JoeAndrieu> q+ to ask how do we define metadata?
15:49:02 <Wip> ack JoeAndrieu
15:49:02 <Zakim> JoeAndrieu, you wanted to ask how do we define metadata?
15:49:04 <manu> 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.
15:49:36 <manu> JoeAndrieu: Do we have a clear definition of metadata? For example, we talk about versionId differently... it's in DID Document vs. Metadata.
15:50:23 <manu> 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?
15:50:26 <JoeAndrieu> q+
15:50:32 <Wip> ack JoeAndrieu
15:50:34 <manu> markus_sabadello: That's the question we're asking... is it in the DID Document or not?
15:51:13 <manu> 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
15:51:14 <manu> q+
15:51:21 <pchampin> s|Those were issues 80, 81, 82, and 83|Those were issues https://github.com/w3c/did-resolution/issues/80 https://github.com/w3c/did-resolution/issues/81 https://github.com/w3c/did-resolution/issues/82 and https://github.com/w3c/did-resolution/issues/83
15:51:28 <Wip> ack manu
15:51:30 <manu> markus_sabadello: This sounds like a bigger issue, maybe we need a separate issue for it.
15:51:35 <pchampin> RRSAgent, draft minutes
15:51:36 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
15:51:44 <bigbluehat> manu: just to push back a tiny bit
15:51:56 <bigbluehat> ... I'm concerned about over specialiazing too early
15:52:11 <bigbluehat> ... if we use the ID and make statements about that subject, that is similar to VCs
15:52:16 <bigbluehat> ...no contest there...agreed
15:52:28 <bigbluehat> ... however, there are other things that can secure that payload
15:52:48 <bigbluehat> ... I think this is a side effect of using a generic data model
15:53:10 <bigbluehat> ... restricting what goes in to a DID document is a good idea
15:53:24 <bigbluehat> ... but I fear painting ourselves into a corner
15:53:32 <bigbluehat> ... and we may put things out of scope unnecessarily
15:54:00 <bigbluehat> ... so I get a little concerned about creating a differing model for DIDs from VCs when the distinction may not be necessary
15:54:37 <manu> markus_sabadello: Ok, so we talked about metadata, architectures, resolution result, dereferencing results, and errors.
15:55:10 <manu> q+
15:55:28 <Wip> ack manu
15:55:28 <manu> markus_sabadello: We can debate error codes or if some are missing or some are considered extensions.
15:55:55 <bigbluehat> manu: we're starting to use the ProblemDetails object from the IETF in some of the VC specs
15:56:06 <bigbluehat> ... I wonder if we might consider that here as well
15:56:13 <bigbluehat> ... have you seen any of that work?
15:56:22 <bigbluehat> ... curious to hear your thoughts on that approach
15:56:32 <bigbluehat> markus_sabadello: I'm aware of it and agree it could be a good fit here
15:56:33 <manu> markus_sabadello: Yes, aware of ProblemDetails object and agree that it could be a good fit here.
15:57:01 <manu> 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.
15:57:18 <manu> Wip: Next time, unless anyone has any issue... we'll spend time doing issue processing on DID Resolution.
15:57:20 <pchampin> RRSAgent, draft minutes
15:57:21 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
15:57:30 <manu> Wip: Thanks everyone, have a great weekend, see you next week.
16:03:53 <pchampin> agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0021.html
16:05:01 <pchampin> agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0021.html
16:05:03 <pchampin> RRSAgent, draft minutes
16:05:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/29-did-minutes.html pchampin
17:07:59 <TallTed> Zakim, bye
17:07:59 <Zakim> leaving.  As of this point the attendees have been Wip, decentralgabe, pchampin, manu, markus_sabadello, dmitriz, bigbluehat, TallTed, JennieM, Smccown
17:07:59 <Zakim> Zakim has left #did
17:08:05 <TallTed> RRSAgent, bye
17:08:05 <RRSAgent> I see no action items