14:43:52 <RRSAgent> RRSAgent has joined #did
14:43:56 <RRSAgent> logging to https://www.w3.org/2024/07/25-did-irc
14:44:06 <Wip> rsagent, draft minutes
14:44:17 <Wip> rrsagent, draft minutes
14:44:18 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/25-did-minutes.html Wip
14:44:32 <Wip> rrsagent, make logs public
14:44:48 <Wip> Meeting: Decentralized Identifier Working Group
14:44:57 <Wip> Chair: Will Abramson
14:58:06 <pchampin> pchampin has joined #did
14:58:34 <pchampin> RRSAgent, make minutes
14:58:36 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/25-did-minutes.html pchampin
14:58:43 <markus_sabadello> markus_sabadello has joined #did
14:59:09 <pchampin> agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0028.html
14:59:40 <pchampin> present+
15:00:03 <decentralgabe> decentralgabe has joined #did
15:00:06 <ivan> present+
15:00:06 <decentralgabe> present+
15:00:47 <markus_sabadello> present+
15:00:59 <andres> andres has joined #did
15:01:08 <andres> present+
15:01:47 <JoeAndrieu> JoeAndrieu has joined #did
15:05:11 <ivan> scribe+
15:05:16 <Wip> Topic: Agenda Review, Introductions
15:05:48 <ChristopherA> ChristopherA has joined #did
15:05:57 <ChristopherA> present+
15:06:50 <manu> present+
15:06:57 <bigbluehat> bigbluehat has joined #did
15:07:02 <JoeAndrieu> present+
15:07:55 <ivan> wip: anyone new today?
15:07:57 <ivan> ...
15:07:58 <ivan> ...
15:08:04 <ivan> ...
15:08:07 <Wip> Wip has joined #did
15:08:07 <manu> q?
15:08:19 <Wip> Topic: Announcement: APAC Meeting Time Poll
15:08:20 <KevinDean> KevinDean has joined #did
15:08:27 <KevinDean> present+
15:08:34 <decentralgabe> https://doodle.com/meeting/participate/id/aK5MXoRd
15:08:35 <ivan> wip: APAC meeting time poll
15:08:45 <JennieM> JennieM has joined #did
15:08:48 <ivan> ... see link about
15:08:51 <JennieM> present+
15:09:01 <ivan> ... we try to close the poll 5pm Wed
15:09:02 <Wip> https://doodle.com/meeting/participate/id/aK5MXoRd
15:09:13 <Wip> Topic: Announcement: First Special Topic Call 7th August
15:09:23 <ivan> Wip: 1st special topic call 7 august
15:09:34 <ivan> ... topic will be about abstract data model
15:09:38 <Wip> https://github.com/w3c/did-core/issues/855
15:09:40 <ivan> ... we give it 2 weeks
15:09:59 <ivan> ... we ask people to reach out to chairs friday next week
15:10:16 <ivan> ... some people do not understand the trade-off of choosing or not choosing
15:10:18 <danpape> danpape has joined #did
15:10:37 <ivan> ... if you have sg to share or an opinion have a presentation
15:10:46 <ivan> ... any comments?
15:10:50 <Wip> q?
15:11:06 <Wip> Topic: DID Resolution
15:11:15 <ivan> wip: hand over to markus
15:12:24 <ivan> markus_sabadello: (slides will be available)
15:23:34 <ChristopherA> q+
15:26:36 <manu> q+
15:26:53 <Wip> ack ChristopherA
15:27:34 <ivan> ChristopherA: my quetion is more of a process/politics question. We were clearly requested that we need to do more formalized did resolution.
15:27:39 <JoeAndrieu> q+ to mention a mandatory to implement interface and against an abstract data model
15:28:19 <ivan> ... That raises the question what part of this normative (to answer their concerns) and what are the things that might create problems.
15:28:44 <ivan> ... eg I am interested by selective disclosure, but I do not know what can be normative, what can not
15:29:01 <ivan> ... I try to understand the dimensions to get this through
15:29:08 <Wip> ack manu
15:29:12 <ivan> Wip: we should plug things into issues
15:29:40 <ivan> manu: thanks Markus. I think the question you highlighted are the right ones.
15:29:56 <markus_sabadello> q+
15:30:08 <ivan> ... in did core things were put there because that was the only place, we should move them now to the resolution spec
15:30:17 <Wip> +1
15:30:34 <ivan> ... what do you need to process the issues, you are the best person to prioritize them
15:30:54 <ivan> ... we should put lot of focus on resolution 3:1 compared to DID Core
15:31:08 <ivan> ... are you planning to prioritize?
15:31:24 <Wip> ack markus_sabadello
15:31:46 <ivan> markus_sabadello: I am happy to hear that we want to move things from core to resolution, it will simplify lots of things
15:32:17 <ivan> ... what would help me is to solve the abstract data model question, that would simplify the resolution process
15:32:27 <ivan> ... i need feedbacks from the wg on the questions
15:33:00 <ivan> ... one thing would be bad if we spend a year on easy topics (eg, error code) and then somebody says that the structure is bad...
15:33:03 <Wip> q+ to agree lets get the big rocks out in the open now. Esp. given TPAC
15:33:31 <Wip> ack JoeAndrieu
15:33:31 <Zakim> JoeAndrieu, you wanted to mention a mandatory to implement interface and against an abstract data model
15:33:31 <ivan> ... getting feedbacks on the high level structure would be important
15:33:43 <ivan> JoeAndrieu: +1 to move resolution out of core
15:34:25 <decentralgabe> +1 to http interface
15:34:29 <manu> q+ to speak to test suites
15:34:35 <ivan> ... a quesiton I like to add is to have a mandatory http interface, but we if we want to answer the concerns we should say that a bona fide method should have an http interface
15:34:59 <Wip> ack JoeAndrieu
15:35:02 <Wip> ack Wip
15:35:02 <Zakim> Wip, you wanted to agree lets get the big rocks out in the open now. Esp. given TPAC
15:35:06 <ivan> ... on the abstract data model: we cannot test that, but having a datatype that we can test would be better
15:35:18 <ivan> Wip: we want indeed to move the big rocks
15:35:28 <Wip> ack manu
15:35:28 <Zakim> manu, you wanted to speak to test suites
15:35:30 <ChristopherA> q?
15:35:30 <ivan> ... we have to decide what we want to put time into
15:35:34 <ChristopherA> q+
15:35:43 <ivan> manu:lots of agreement with what ChristopherA and JoeAndrieu said
15:35:51 <markus_sabadello> q+
15:35:59 <ivan> ... we have to talk about test suites as well, to address criticisms
15:36:12 <ivan> ... having an http based test suite will be useful
15:36:34 <ivan> ... if we do that we can point to a concrete api
15:36:45 <ivan> ... we already have a test suite for did, but it is not adequate
15:36:56 <ivan> ... we may want to spend time a did 'linter'
15:37:04 <ivan> ... it is not difficult but would be useful
15:37:08 <ChristopherA> Is a did "linter" really a controller document "linter"?
15:37:14 <ivan> ... it would give the community a usefule tool
15:37:27 <ivan> ... it would be easy to do
15:37:39 <ivan> ... maybe a resolution sofware could include it
15:37:55 <ivan> ... +1 to Joe, we need an http api, it woul help us to test suites
15:38:15 <ivan> ... Ideally, we should have a test suite in about 6 months
15:38:25 <Wip> ack ChristopherA
15:39:12 <ivan> ChristopherA: which of these things (the misc page on the presentation) would put us at risk at the end
15:39:15 <manu> q+
15:39:25 <manu> q+ to speak to risks
15:39:27 <ivan> ... i try to get a feel to see which are risky
15:39:29 <Wip> ack markus_sabadello
15:39:58 <ivan> markus_sabadello: you mean list (page 9)? I do not think any of these are critical
15:40:19 <ivan> ... the big ones are the arch designs and the bindings; these are minor issues
15:40:31 <ivan> ... we can also use the registry to add error codes, for example
15:40:41 <ivan> ... we can use extension, not in the spec itself
15:40:49 <ChristopherA> q+ about "trust in did resolution"/"authentication"/"encryption"
15:40:54 <ChristopherA> q+ to "trust in did resolution"/"authentication"/"encryption"
15:40:54 <ivan> ... i see these as less risky
15:41:28 <ivan> ... we also did a linter project, will share that as well
15:41:32 <Wip> ack manu
15:41:32 <Zakim> manu, you wanted to speak to risks
15:41:44 <markus_sabadello> DID Resolution test suite: https://github.com/w3c-ccg/did-resolution-test-suite
15:41:55 <markus_sabadello> DID Lint / Validator: https://didlint.ownyourdata.eu/
15:42:11 <ivan> manu: on the risks, I agree with markus, I do not think there is any risk, we can put anything in it that does not exceed the charter
15:42:26 <ivan> ... per the core, with the changes may be risky
15:42:55 <ivan> ... eg, we may point to the credential doc and that may be risky, but it will be out there earlier
15:43:46 <ivan> ... the abstract data model removal may be a bigger risky, but that is not testable, so it is more problemantic, and if there are other represenations (cbor, yaml, etc), we may get
15:44:49 <ivan> ... unfriendly comments. But we can re-write so that other data formats should be possible to do that. But if we pick a serialziation in the core model, that can lead to objections either without or outside the group.
15:45:03 <Wip> ack ChristopherA
15:45:03 <Zakim> ChristopherA, you wanted to "trust in did resolution"/"authentication"/"encryption"
15:45:10 <Stephan> Stephan has joined #DID
15:46:06 <ivan> ChristopherA: I am still concerned, I do not know what they former objector's opposition to the resolution (eg, get this in the browser), that means an internal API which is not http\
15:46:13 <ivan> I am a bit confused
15:46:24 <manu> q+ to speak to comment on Apple, Google, and Mozilla's perceived concerns.
15:46:53 <ivan> ... I prefer to the abstract data model in the core and the resolution should be very specific, it can do tight conformance in json, or http
15:47:08 <ivan> ... the did core 1.1 will not say that you MUST use did resolution
15:47:38 <ivan> ... some may different model for selective disclosure, for example,
15:48:00 <Wip> ack manu
15:48:00 <Zakim> manu, you wanted to speak to comment on Apple, Google, and Mozilla's perceived concerns.
15:48:04 <ivan> ... the did resolution is zero constraint and help the did core documen where it is not precise enough
15:48:40 <markus_sabadello> q+
15:49:18 <ivan> manu: the concerns raised during the previous specs; if we can demonstrate that we have interoperability better than before, I do not think it matters whether it is resolution or not
15:49:38 <Wip> zakim, close the queue
15:49:38 <Zakim> ok, Wip, the speaker queue is closed
15:49:44 <ivan> ... they were starting to " just show use at least one interoperable method"
15:50:00 <ivan> ... we have that already
15:50:15 <ChristopherA> q+ to "trust in did resolution"/"authentication"/"encryption"/"sd"
15:50:40 <ivan> ... then there was a request you referred to some method that are really decentrilized, not like, eg, did:web
15:51:06 <ivan> ... there are couple of layers, and each organizations asked different things
15:51:36 <ivan> ... but if we get back the same did document from different software, for example, we would prove interoperability
15:51:48 <ivan> ... we do not standardize specific did methos
15:52:11 <Wip> ack markus_sabadello
15:52:16 <ivan> ... that should address the initial formal objections, and we are in a stronger position now
15:52:40 <bigbluehat> present+
15:52:52 <ChristopherA> I'd like to add to a future agenda, if how much we have to define for "trust in did resolution"/"authentication"/"encryption"/"sd"
15:53:08 <Wip> I suggest adding an issue ChristopherA
15:53:10 <ivan> markus_sabadello: thanks for bringing all this up, i agree with this deliverable will prove the requirements the community has, the http binding will help further
15:53:35 <ivan> ... at the last tpac tehre were also a number of ideas
15:53:59 <ivan> ... eg, supported methods by a resolver can be discoverable
15:54:04 <JoeAndrieu> +1 to support redirection / discovery of other resolvers
15:54:33 <ivan> Wip: thanks for this presentation
15:54:43 <Wip> Topic: Next Up: DID Method Registries
15:54:45 <ivan> ... remind you to get the issues in
15:54:51 <Wip> https://github.com/w3c/did-spec-registries/issues/568
15:55:16 <ivan> ... next week we will discuss registry again and that issue ^ on how to split up the registry
15:55:40 <ivan> ... thanks everyone
15:55:57 <ivan> rrsagent, draft minutes
15:55:58 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/25-did-minutes.html ivan
18:07:07 <Zakim> Zakim has left #did
19:01:13 <TallTed> TallTed has joined #did