Meeting minutes
<Wip> rsagent, draft minutes
Agenda Review, Introductions
wip: anyone new today?
…
…
…
Announcement: APAC Meeting Time Poll
<decentralgabe> https://
wip: APAC meeting time poll
… see link about
… we try to close the poll 5pm Wed
Announcement: First Special Topic Call 7th August
Wip: 1st special topic call 7 august
… topic will be about abstract data model
<Wip> w3c/
Wip: we give it 2 weeks
… we ask people to reach out to chairs friday next week
… some people do not understand the trade-off of choosing or not choosing
… if you have sg to share or an opinion have a presentation
… any comments?
DID Resolution
wip: hand over to markus
markus_sabadello: (slides will be available)
ChristopherA: my quetion is more of a process/politics question. We were clearly requested that we need to do more formalized did resolution.
… That raises the question what part of this normative (to answer their concerns) and what are the things that might create problems.
… eg I am interested by selective disclosure, but I do not know what can be normative, what can not
… I try to understand the dimensions to get this through
Wip: we should plug things into issues
manu: thanks Markus. I think the question you highlighted are the right ones.
… in did core things were put there because that was the only place, we should move them now to the resolution spec
<Wip> +1
manu: what do you need to process the issues, you are the best person to prioritize them
… we should put lot of focus on resolution 3:1 compared to DID Core
… are you planning to prioritize?
markus_sabadello: I am happy to hear that we want to move things from core to resolution, it will simplify lots of things
… what would help me is to solve the abstract data model question, that would simplify the resolution process
… i need feedbacks from the wg on the questions
… 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...
<Zakim> JoeAndrieu, you wanted to mention a mandatory to implement interface and against an abstract data model
markus_sabadello: getting feedbacks on the high level structure would be important
JoeAndrieu: +1 to move resolution out of core
<decentralgabe> +1 to http interface
JoeAndrieu: 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
<Zakim> Wip, you wanted to agree lets get the big rocks out in the open now. Esp. given TPAC
JoeAndrieu: on the abstract data model: we cannot test that, but having a datatype that we can test would be better
Wip: we want indeed to move the big rocks
<Zakim> manu, you wanted to speak to test suites
Wip: we have to decide what we want to put time into
manu: lots of agreement with what ChristopherA and JoeAndrieu said
… we have to talk about test suites as well, to address criticisms
… having an http based test suite will be useful
… if we do that we can point to a concrete api
… we already have a test suite for did, but it is not adequate
… we may want to spend time a did 'linter'
… it is not difficult but would be useful
<ChristopherA> Is a did "linter" really a controller document "linter"?
manu: it would give the community a usefule tool
… it would be easy to do
… maybe a resolution sofware could include it
… +1 to Joe, we need an http api, it woul help us to test suites
… Ideally, we should have a test suite in about 6 months
ChristopherA: which of these things (the misc page on the presentation) would put us at risk at the end
… i try to get a feel to see which are risky
markus_sabadello: you mean list (page 9)? I do not think any of these are critical
… the big ones are the arch designs and the bindings; these are minor issues
… we can also use the registry to add error codes, for example
… we can use extension, not in the spec itself
… i see these as less risky
… we also did a linter project, will share that as well
<Zakim> manu, you wanted to speak to risks
<markus_sabadello> DID Resolution test suite: w3c-ccg/
<markus_sabadello> DID Lint / Validator: https://
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
… per the core, with the changes may be risky
… eg, we may point to the credential doc and that may be risky, but it will be out there earlier
… 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
… 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.
<Zakim> ChristopherA, you wanted to "trust in did resolution"/"authentication"/"encryption"
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\
I am a bit confused
… 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
… the did core 1.1 will not say that you MUST use did resolution
… some may different model for selective disclosure, for example,
… the did resolution is zero constraint and help the did core documen where it is not precise enough
<Zakim> manu, you wanted to speak to comment on Apple, Google, and Mozilla's perceived concerns.
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
… they were starting to " just show use at least one interoperable method"
… we have that already
… then there was a request you referred to some method that are really decentrilized, not like, eg, did:web
… there are couple of layers, and each organizations asked different things
… but if we get back the same did document from different software, for example, we would prove interoperability
… we do not standardize specific did methos
… that should address the initial formal objections, and we are in a stronger position now
<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"
<Wip> I suggest adding an issue ChristopherA
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
… at the last tpac tehre were also a number of ideas
… eg, supported methods by a resolver can be discoverable
<JoeAndrieu> +1 to support redirection / discovery of other resolvers
Wip: thanks for this presentation
Next Up: DID Method Registries
Wip: remind you to get the issues in
<Wip> w3c/
Wip: next week we will discuss registry again and that issue ^ on how to split up the registry
… thanks everyone