Meeting minutes
ottomorac: couple of topics today, we'll mention the special topic call yesterday, issue processing, did resolution
manu: one thing on the review of DID Resolution. miraculously, the TAG has changed the review process based on our input
… on not having to write explainers for things
… I think it'll be good for us to try and use the new process for DID Resolution, but wanted to check with the group if others agree
ottomorac: sounds good
DID Methods WG Charter - Special Topic Call Debrief
<ottomorac> https://
ottomorac: does anyone want to comment on the call?
manu: one of the other interesting things that happened - we're explicitly not putting blockchain out of scope
… we're saying, if whatever you're calling blockchain is compatible with Web Architecture, that's fine
… that opens up the charter a bit. we'll just have to see what the AC feels about that, if anything
<ottomorac> q_
GDC Conference Debrief
Wip: one of the sessions I attended is - how sovereign states can support FOSS tech better
… particularly in the EU, they have several Sovereign Tech Funds
… maybe we can reach out to them to these funds, see if they're interested in helping us with some of the work we have to do?
<Zakim> manu, you wanted to ask if anything DID-specific was discussed?
manu: did anyone go to any sessions where DIDs were mentioned at all?
… last year, some of the conversation in EU was "we're not going to use DIDs since there's no standardized DID methods"
… that got some pushback from EBSI, others in the EU
… based on that, we've been having this DID Methods WG chartering discussion
… to standardize some of the DID methods
… so, just checkign if anyone heard much discussion on DIDs at GDC
markus_sabadello: I was also there, I did have my own sessions (so did have a presentation on DIDs)
… kept it quite generic / intro level to explain DIDs and how they work
… and current state in the community
… so that was one. there were also several other sessions
… much of the topics were focused on wallets / governments
… some members of the community mentioned standardizing DIDs for the EU
… Kim from DIF was there, mentioned DID standardization efforts
… one session I thought was exciting was from some orgs from South Korea, representatives from the Korean gov't and startups
… they mentioned DIDs in a positive way
… specifically how it helped them reach interop between COVID credentials between Korea and Singapore
… so, same data model as DIDs and VCs, said the abstraction helped them achieve interop, etc
Dimitriz: Yes, MIT was one of the organizers of the conference. I was not there, but we do implicitly work on DIDs and were present there
brent: other sessions where DIDs came up were the Trade session
… and DIDs were a core component. (also folks from SE Asia)
ottomorac: I heard similar, re SE Asia
<bengo> There was a presentation on "China-Singapore-Hong Kong Cross-border Decentralized Identity and Credential Trials and Use Cases" that seemed to use solana but i don't remember if it used DIDs.
manu: ok, DID Resolution. I ended up merging some of the PRs,
… so that leaves us 2 issues that are new
DID Resolution Updated TAG Process
manu: ok, TAG asked us to write a new Explainer for DIDs.
<JoeAndrieu> https://
<manu> Explainers: w3ctag/
manu: I did that using AI, to see if that can speed that up, and some folks on the TAG pushed back to say they're not sure if they're comfortable with that
… I pointed out that Explainers are an anti-pattern. that the spec itself should be explainable enough
… there was a long conversation that happened, the last 2-3 months
… but! it resulted in the TAG significantly changing their review process. Explainers no longer required, as long as the spec is understandable (contains the contents they're looking for)
… Jeffrey Yaskin put in a lot of work into it
… the goal here was to make the spec defend/explain itself, instead of a separate explainer doc
… so, for now, we can just link to the sessions in our DID spec that explains stuff, rather than separate doc
… for DID Core 1.1, they already did the review and were fine with it
… basically, I think we're ok with DID Core, passed the TAG horizontal review
… DID Resolution did not go through the review
… so question for us is -- do we want to write an Explainer? Because there's an opportunity here to not, to just point to sections in the DID Res spec
… to address the open issue about the did resolution explainer
… I suggest that we run the new process, because long term it reduces editor work load
… but it's up to the editors and chairs
markus_sabadello: I think that makes a lot of sense, to use the new approach
… I wonder if it makes sense to try and have everything that's supposed to be in the Explainer in one section (like Introduction). or spread across multiple?
manu: I think 80% of it can go into the intro. when we did the analysis on what an Explainer does,
… it turns out 80% of the content should go into Introduction
… things like - what does the spec do, why did you create it, what kind of problems does it address
… there is one part of it that doesn't really, which is - what are the alternate technologies you considered? that could go into the Appendix
… the question of What kind of user-facing problems does the spec address? we could just point to the DID Use Cases doc
… so we could try that, see if they complain
ottomorac: ok, I don't think we have any relevant PRs...
markus_sabadello: one more thing about horizontal review process
… the other things we have to do have not changed, right? i18n, accessibility, etc?
manu: correct
… we may want to let them know we're following the new TAG process for explainers, point to the issue
… in lieu of the explainer link. that's the only modification we need there
DID Resolution Issue Processing
ottomorac: ok, switching over to DID Res issue processing
Is the openAPI spec (eventually) normative or informative? #118
<ottomorac> w3c/
ottomorac: 118 - is OpenAPI spec going to be normative or informative
… Open question as to whether the reference to OpenAPI spec is normative or informative.There was also a question about whether we can use .OAS files for the example.
<bengo> dmitriz there is also https://
<bengo> (RT != endorsement)
markus_sabadello: I don't really know the answer to that, re OpenAPI,
… maybe informative?
… because we're actually defining HTTP binding for DID Res in the spec itself?
… so OpenAPI is just a useful additional construct
… so, not normative
ottomorac: there's also comment from Ivan - what happens when there's a conflict between spec text and OpenAPI definition?
manu: two thoughts - one is, we've been dealing with the same issue in the VC API spec for 3+ years
<manu> digitalbazaar/
manu: it led us to create a plug-in for Respec called Respec-OAS
… what this does is ensure the alignment between spec text and OAS file
… so, it takes the OAS file as input, prints it out using RFC language
… it's a bit wordy and verbose, and may not be the approach here. but just noting there's that tool
… we're actively using/maintaining it tho
… comment two - if we don't more tightly bind the two, then the OAS file should be non-normative
… so as not to lead to spec mis-implementation etc
<bengo> Ideally the normative text is in plain language, and I'm not sure OAS is
manu: so, either unify the two via the tool, or make OAS non-normative.
<bengo> (great tool for devs, not for readers)
manu: re bengo's comment -- that is exactly what the plugin tries to do, convert the OAS language into normative plain text
bengo: yeah, was just agreeing with you
ottomorac: markus, do you need some time to think on it?
markus_sabadello: my preference would be to keep it informative for now
… rather than setting up the plugin for the time being
… since it's a very simple one endpoint API
<manu> agree that it's a simple API and probably don't need the overhead of respec-oas.
<bengo> manu if the spec loads the OAS then the 'plain language' can still be normative even if the OAS is not. only it's conversion to plain language needs to be normative imho.
markus_sabadello: so, we just define spec text as normative, reference the OA as informative.
<manu> bengo, hmm, ok I think I understand what you mean -- and is what happens today w/ respec-oas (the OAS is never normative)
ottomorac: ok, so the resolution is -- move the OAS file to a DIF repo, and reference it as informative
<bengo> manu i love that, thanks for making respec-oas
Model accept as the HTTP accept header #116
<ottomorac> w3c/
ottomorac: The was a suggestion from Ivan to model the “accept” properties (both of DID and for DID URL) after the HTTP Accept header syntax. The suggestion was positively received by Markus. What would be the next steps here?
markus_sabadello: background was - when you invoke a resolver, you can pass the Accept header
… maybe the significance of this has changed a bit after we moved away from Abstract Data Model. but still has the same overall function as in HTTP
… even if at the moment we allow only a single mime type
… but in DID URL Dereferencing, we might have many different media types
<Zakim> manu, you wanted to agree, model after HTTP Accept.
manu: +1 to what Markus said, and what Ivan was suggesting
… lets not reinvent the wheel and just model it after the HTTP accept header
ottomorac: ok, consensus is to model it after HTTP Header, change the DID resolution algorithm.
… do we just label the issue as Ready for PR?
markus_sabadello: yes
Proposal: Define DDO as "DID Descriptor Object" that can bootstrap into EDO "Entity Descriptor Object" #45
<ottomorac> w3c/
<ottomorac> There was a suggestion by Will that we incorporate at least of the 2 suggestions from Chris Allen about intermediate did documents and how did methods define interim pieces that eventually form DID documents.
WIp: there are some changes we can make, I'm not sure where they fit
… there's a couple of PRs that are similar. my querstion to the group -- based on having merged this PR in DID Core, is that sufficient, or do we also want to add something to the Resolver spec?
manu: I don't think we want to use the terms DDO and EDO anymore
… because of exactly what Will said -- we can just call them Intermediate DID Docs, and Resolved DID Docs
… the major concern is - we don't want to add more specialized DID terms
… ideally, we want to minimize those
markus_sabadello: agreed, we definitely don't want to introduce terms DDO and EDO. the question is - do we want to mention anything about Intermediate DID Docs, during resolution process?
… but as Will also mentioned, there was an issue merged today in DID Core, which talks about that a bit
<ottomorac> w3c/
markus_sabadello: w3c/
… also the Read operation is defined by the DID Method, and that does whatever, in regards to the Intermediate DID doc
… so, we probably don't need to change spec
<Wip> +1 I think I agree
<Wip> I am advocating we do nothing :)
bengo: I'm noticing that nobody's advocating for this except Wip, who is +1 on this currently
… and my instinct is -- I don't see a reason to recommend against it, but maybe Wip does
Wip: yeah, to be clear, I'm not actually advocating we do anything
<bengo> I'd probably be -1 on adding that language without understanding a rationale.
<bengo> let's close the issue
Wip: we already say DID Resolvers must return conforming DID Docs, not intermediate ones, so, no change needed
<manu> +1 to what Will is saying... I'm hearing that the folks providing an opinion are aligned.
markus_sabadello: ok, I'll add these comments to the issue and we'll mark it pending closed
Restricted access/Authentication/Authorization #38
<ottomorac> w3c/
<ottomorac> Related to concern raised by JoeA, that if you cannot get to the DID document itself, then whomever is preventing that access becomes the new gate-keeping authority. The agreement from the last discussion was we should probably get Christopher Allen’s opinion or maybe have a special topic call about this subject.
ottomorac: it's been some time since we discussed it, so -- is that still the sentiment here, or do we take another route?
manu: looking back to what Joe said initially, I think he's just saying - the current language doesn't make it clear if Authn is out of scope, or allowed
… I think it is allowed. so, we can address the issue 'authn to the DID Res API is allowed, but is out of scope'
markus_sabadello: I agree. this topic comes up rarely. usually we consider DID Resolution to be public
<bengo> an interop profile can be made about how the resolver (if http) can use WWW-Authenticate header to indicate supported authz schemes in a HATEOAS way.
markus_sabadello: so, we can point out that it's allowed, but extensions can use auth* mechanisms
Wip: I agree it should be allowed. I just wanted to flag, is there anything about a DID Method that needs to do to be conformant? Such as, require at least one publically accessible resolver endpoint for it
<Zakim> JoeAndrieu, you wanted to say discouraging would be good
JoeAndrieu: I'm pretty opposed to that. requiring any DID Method to stand up a resolvable service would centralize us, etc
… I think auth should be allowed, but discouraged
… so, if you can introduce a gatekeeper, then.. it'll gate keep
<Zakim> manu, you wanted to note we can't stop bad ideas :)
manu: +1 to both things Joe said
<smccown> +1 to Joe's comments about not introducing new gatekeepers
manu: we should also tell people that they should not need a public endpoint, even if we don't require it
… but we shouldn't add normative statements about bad ideas in the spec. (even to discourage them)
… nothing we write can prevent bad ideas, so let's just have language that promotes good ones
Dmitriz: So I want to clarify this to authentication on the resolver?
Dmitriz: we want to encourage folks to use local resolvers, and use the public ones only as a last resort right?
<bengo> https://
Dmitriz: Just want to clarify that most authorization / access would require local and we should require a public endpoint
bengo: I heard Joe mention a concern about something leading to a reliance on DNS
… and just wanted to point out that LetsEncrypt now hands out TLS certs to just IP addresses (without DNS)
… so, I don't think reliance on DNS is main danger ehre
smccown: thank you, great comments. I wanted to point out that there are privacy implications. adding new gatekeepers gives them a new bird's eye view on who's asking for what
… I agree that we shouldn't include bad ideas / negative concerns in the spec. but we can emphasize local lookups / local resolvers, as opposed to a public resolver (which can collect usage data etc)
<Wip> smccown I tried to capture some of that in this PR. Be great to get your reveiw - w3c/
markus_sabadello: regarding to what Steve just said about usage data / birds eye view. The one open PR that we have in DID Res right now is about that
… Wip wrote some language about privacy considerations, talk about the risks. so, the PR could use more reviews
<Wip> All good :)
<bengo> Wip I added a +1 to your PR
markus_sabadello: so, we don't want to add normative language about auth required for the DID Method itself. but auth for resolvers is separate - we could mention those in the specs
<Zakim> manu, you wanted to note OHTTP statements in DID Resolution?
<JoeAndrieu> btw, +1 to Dmitri's argument.
<manu> https://
<bengo> It would be pretty great to nod to OHTTP with a MAY at least
<bengo> (or no text)
<bengo> https://
<bengo> ^ OHTTP
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/