Meeting minutes
Manu: One more item for the agenda. Update on the reviews for DID Core
Possible liaison with ISO/TC 307/JWG 4
<Zakim> JoeAndrieu, you wanted to say Phillipe should raise his concerns here
<Zakim> update, you wanted to comment on reviews
Group has been invited by Julian to have relationship with WG, which is specifically focused on blockchain standardization.
Invite Philippe to the next call to discuss
<JoeAndrieu> Yep. Not a legitimate technical concern
<JoeAndrieu> Btw, I'm not available for the literal next call. Might be a good special topic call
<JoeAndrieu> agreed. like my own formal objections over staff's continued anit-blockchain position
Manu: We can do our work effectively without a formal working relationship in place with ISO TC 307. We can provide feedback. They do their work in public. No problem with that. Separate concern with certain entities at W3C taking positions without having data on specific blockchain technologies. We need to be careful with the teams' time, it
should be used when needed.
Otto: Motion to have a special topic call on this. Up to the chairs
Summary of Special Topic Call from DID Linked Resources
tweeddalex: It was a productive call, described did linked resources, and its uses and clarified some misconceptions....
tweeddalex: clarified relationship with did:web....
tweeddalex: gave examples of usages of did linked resources... agreed that there needs to be a spectrum for best practices for storing did linked resources....
tweeddalex: Joe has a extension in the did spec for that, agreed that this could be linked with that....
tweeddalex: productive call and clarified some aspects of how blockchains can facilitate the aspects of did linked resources...
manu: yes we had some action items.... wondering if we can fold that into the regular meetings...
manu: request that Alex and Ankur discuss with chairs about folding this into the regular meetings....
manu: may want to create an issue from each of the 4 action items.... we can discuss during editors call....
manu: take a holistic look at the four issues raised on the special topic call and fold that into subsequent discussions
Horizontal Review Update
Manu: I was able to get the security and privacy review completed.
<manu> Horizontal review tracking issue: w3cping/
<manu> Security and Privacy Review: w3c/
Manu: Did the security and privacy review with AI to test whether it is at the level to do things like this. Manu reviewed every single answer, but overall, it did a pretty good job - which otherwise would have taken multiple days to fill out. That allowed us to submit the privacy and security group requests.
<manu> w3ctag/
Manu: The explainer discussion raises the question of where does AI fit within W3C, what are the scopes on its boundaries around security and privacy reviews.
Manu: Going back to blockchains and resources uses, it will be interesting to see if anti-blockchain folks are also anti-ai - as both can use lots of energy
DID Core Issue Processing
884 - DID needs a proper vocabulary specification
We need a vocabulary for the DID spec, we are currently kind of borrowing it from the CID spec. Group decision was to only use JSON for DID resolution (we can add JSON-LD option later). Also Manu suggested the media type application/did-resolutionIvan found some vocab files, probably from Amy Guy that required some adjustments,and decided to create
new ones. The question is now where to locate the vocab files.
<ottomorac> w3c/
ivan: looked at the files done by Amy, there were quite a lot of changes that should have been done (e.g. CID) and other references. Should keep old ones for the sake of history. Have all the vocabulary files ready, unsure where to put them. Maybe not the DID Spec extension. They are core documents, rather than extensions. 1st proposal DID Core
repository? Or, (2nd) in a way that the vocabularies would be automatically generated. Whole PR material is ready
ivan github action file that should be reviewed properly (by Manu if possible)
ivan the tool can also generate context files. The files that are generated are better than the current official DID context file (which omits certain terms, making the example in the document invalid). E.g. it doesn't have terms for multi-keys. The question is whether we use the same tool to generate the context file, or generate it manually.
<Zakim> manu, you wanted to agree that this shouldn't go into DID Extensions.
manu agrees, this shouldn't go into DID Extensions. It should go with the main spec, like we have done for verifiable credentials. Complements the tooling Ivan has created - automatic generation is preferable
manu thinks we can generate all of it automatically and plus 1 to the idea
ivan: to raise the PR tomorrow, as its all ready
842 - Request for Guidance on Normalization Rules Enforcement
<ottomorac> w3c/
This is related to normalization rules for string URIs in the serviceEndpoint property
Kevin says: We might want to add to the spec to say, that all rules for normalization and canonicalization are defined in the URL standard. That addresses this issue
Kevin Dean took on the issue and suggested a change, however Will pointed that we may not change CID spec and bringing that in would require a re-charter.
Kevin: the text has been rewritten so its no longer ambiguous
ottomorac: should we close the issue? Answer defer to after recharter
831 - Fix assertion narrative clearly define the authoritative claims made when DID Key Controllers are not the DID Controller of the Document
<ottomorac> w3c/
ottomorac there was some discussion that Joe would do a PR for the above
JoeAndrieu acknowledged
880 - Relative DID URLs
<ottomorac> w3c/
ottomorac: Issue raised by Fabio Pinheiro, does this change based on the special topic call?
manu: think Markus' suggestion is right and should address the issue
markus_sabadello: doesn't have anything to do with special topic call. Its just when we use DID URL vs relative DID URL. Fabio who created the issue is right. We should clarify this verificationMethod logic a bit more - it can also be a relative DID URL
<manu> s/ markus_sabadello doesn't/markus_sabadello: doesn't/
DID Resolution Issue: Handling DID resolution after a distributed system fork
<ottomorac> w3c/
Summary: Agreed on some of the complex aspects of distributed system forks. General direction is we should add an item on security considerations. Question now is if it should be on did-core or did-resolution or both?
ottomorac Kyle's comment suggest it belongs in both
markus_sabadello one a recent call we said that this should be up to DID Methods. It could be mentioned within DID Resolution. Doesn't need to be added to DID Core. Not so much about the data model and the identifier, just the resolution
<JoeAndrieu> +1 to is being resolution if anywhere
tweeddalex: +1 as well
DID Resolution Issue Processing
83 - Discover DIDs from other identifiers
Summary: DIDs can potentially be discovered from other identifiers such as HTTP URIs, domain names, or email addresses and how this could be managed in the did-resolution spec.Connected with DIF .well-known/did-configuration
<ottomorac> w3c/
<Zakim> JoeAndrieu, you wanted to say this is out of scope
ottomorac notes that markus_sabadello mentions that this is correlated with the well.known path defined by DIF
JoeAndrieu you can discover DIDs from anywhere, so it isn't really relevant or within scope
<dmitriz> I agree with Joe. It's out of scope (in that, it can be specified in a separate spec)
markus_sabadello could consider out of scope. Think that's fine. Or brief aside somewhere
markus_sabadello there are some initiatives for bidirectional bridging
tweeddalex: I have been leading an effort in Trust Over IP related to this on create binding x509 certificates and did indentifiers....
tweeddalex: the spec defines resolution patterns... but may deserve its own issue...
<Zakim> manu, you wanted to note out of scope for now
manu agree with Joe and Dmitri (for now). There is active work in the space. At Digital Bazaar there is a deep interest in bridging between X.509 and DID Documents (many orgs want that type of bridging). Its a very interesting area where we should put more thought into this. The way the issue is currently worded, its too broad. Its always possible
to discover identifiers from others. Not really worth pointing to different ways of doing this. It would be really nice to specify a general pattern that multiple identifier formats can adopt (specifically on X.509 and DIDs - that would be worth its own issue)
> manu agree with Joe and Dmitri (for now). There is active work in the space. At Digital Bazaar there is a deep interest in bridging between X.509 and DID Documents (many orgs want that type of bridging). Its a very interesting area where we should put more thought into this. The way the issue is currently worded, its too broad. Its always
possible to discover identifiers from others. Not really worth pointing to different ways of doing this. It would be really nice to specify a general pattern that multiple identifier formats can adopt (specifically on X.509 and DIDs - that would be worth its own issue)
DID Resolution Pull Request Reviews
<ottomorac> https://
<ottomorac> w3c/
<ottomorac> Define resolution results as JSON, not JSON-LD
Define resolution results as JSON, not JSON-LD
markus_sabadello there is consensus in using plain JSON, rather than JSON-LD for DID resolution. PR seeks to address that change
Issue #17 - Relationship between DID Resolution spec and DID Core #151
<Zakim> JoeAndrieu, you wanted to ask about how this relates to Ivan's work
JoeAndrieu did we talk earlier about Ivan do work that would potentially be unnecessary if we adopt this position. Worth clarifying
Issue #17 - Relationship between DID Resolution spec and DID Core #151
ivan mistaken. As we are discussing whether there should a JSON-LD dialect for DID Resoltuion. Ivan did not touch this. He worked on the DID spec vocabulary
<ottomorac> w3c/
Summary: This PR addresses the question in Issue #17, which questioned whether the DID Resolution specification is a layer above the core DID specification.
<smccown> It also addresses Issue #18 as they are similar
markus_sabadello this is good to address (they have been there a very long time). Just on clarification between the relationships between DID Resolution and DID Core. Steve did a great job explaining it
Migrate errors to use problem details#146
<ottomorac> w3c/
markus_sabadello this PR was about aligning the error codes in DID Resolution and using construct of problem details for aligning DIDs with CID spec. Would also like to merge. May be a few future iterations. Good enough for now
W3ID
manu we are using w3id URLs (had a big discussion in VC WG). We concluded that we could use these. Arguments against w3id as not under an SDO, etc. ISO has claimed space on w3id.org which is very strange, given they have their own domain... They claimed the standards tree, but that is interesting - and semi-legitimizes their use
manu maybe we hand the keys to the site over to other standards orgs? Might be worth a discussion
ivan what do they want to use it for (ISO)?
manu its in a PR request to be sent around...
<manu> It's this PR on w3id.org: perma-id/
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> issue w3c/
<m2gbot> comment created: w3c/