Meeting minutes
Agenda Review
Wip: We will discuss a few topics today including ISO WG Liason, DID Resolution issues among others...
ISO/TC 307/JWG 4 Liason
pchampin: Yes to update everyone. I met with Julien Bringer in Geneva. We are figuring out if we have type C or type A liasion.....
pchampin: Type C is for WG only, type A is for comittee level liason....
pchampin: We need to decide makes the most sense for W3C. Julien will circle back with me with his feedback on this.
Wip: I know that Kevin Dean is intending in participating in this group....
Kevin Dean: Yes, the focus of the ISO TC 307 is focused on Blockchain and DLT. The work item that is of interest is the security, privacy, and identity item....
KevinDean: There is no indication of any future work on that...
KevinDean: the other area of interest is "Smart Contracts and their application"... There has been a preliminary report issued on that item.
KevinDean: This group is set to reconvene on November in Australia. There has not been much recent activity on the group.
<Zakim> JoeAndrieu, you wanted to mention GDC
JoeAndrieu: One of the sessions at GDC was run by this group, they were discussion on organizational identity on blockchain...
Wip: Perhaps we should have Pierre reach out to Julien Bringer so he can briefly present us more details about this ISO TC 307 effort...
pchampin: The main liason we were aiming to link with was WG 4, related to identity
DID Test Suite Special Topic - 23rd July
<Wip> w3c/
Wip: We will hold this special topic call focused on test suite, I have run the Digital Bazaar script to extract all the MUST statements from the spec...
Wip: We will discuss what a test might look like.. if you are interested in this work please join the wg call next week
HTTP Post Binding for DID Resolution
<Wip> w3c/
markus_sabadello: if a client calls a resolver over https right now this is done using GET, however the issue poster would like to also allow this to be done with POST...
markus_sabadello: There is a potential issue when resolution option parameters are too many this may cause issues with using GET...
markus_sabadello: These issues have to do with HTTPS binding... so the question is do we want replace the GET approach or allow both GET and POST
Wip: What are the good arguments to keep using GET?
markus_sabadello: GET is simpler and it works directly in the browser... Also there are some caching semantics that work better with GET than POST...
<JoeAndrieu> FWIW, The ISO blockahin discussion at GDC was about ISO 23042 (Reference architecture for blockchain-based decentralized identity systems)
<JoeAndrieu> From https://
<JoeAndrieu> ---
<JoeAndrieu> Security and Interoperability Standardization for Wallets
<JoeAndrieu> One-hour workshop at GDC 2025 uniting BGIN and ISO experts to present ISO 23042 (Reference architecture for blockchain-based decentralized identity systems) under development and forthcoming wallet-security related standards, showcase BGIN cybersecurity streams, and engage regulators, vendors, and researchers on implementing and managing secure,
<JoeAndrieu> interoperable digital wallets.
<JoeAndrieu> Speakers
Wip: I think then perhaps we should keep both of them
<JoeAndrieu> Julien Bringer (ISO/TC 307/JWG 4, BGIN) Mitchell Traves (BGIN) Carole House (BGIN) Paolo Campegiani (ISO 23042) Shin'ichiro Matsuo (Moderator)
<JoeAndrieu> ---
markus_sabadello: I am interested to hear other opinions but I think we should indeed keep both....
<pchampin> https://
markus_sabadello: perhaps GET can be used when you have fewer resolution options and use POST when want to have access to all functionality and not be restricted
<bengo> Oh yes I have been planning to use QUERY for wallet.storage
pchampin: there is also some work on IETF that allows you to add payloads to a query...
pchampin: this could be interesting here
JoeAndrieu: I am not in favor of keeping both because it could harm interoperability. However would like to ask about http and https?
JoeAndrieu: The 4000 character limit is just a platform limitation, I would like to see more examples of GET actually breaking and not being sufficient...
pchampin: I have seen some examples with SPARQL, but this is not a big issue really
markus_sabadello: Yes in SPARQL, both are allowed however Joe might be right that the character limit is not a good argument
markus_sabadello: There could still be ways that we can do resolution without using POST
markus_sabadello: The DID resolution could also be encoded as JSON in the QUERY string
<Zakim> bengo, you wanted to talk about interoperability *of intermediate caching proxies* which is imho where GET/POST is not enough but is critical to scalability which is not something SPARQL endpoints are known for.
bengo: Yes Cloudflare is one of the Authors in that QUERY ietf draft
bengo: You could also use the content-type header....
DID Resolution PR Processing
w3c/did-resolution#157
Wip: This one has been open for a month...
smccown: Depending on how DID methods are implemented they can be somewhat centralized... I was talking to Stephen Curran that may not always be the case with did:webvh... You can still host your did-docs in a variety of locations... This also applies to did:keri because of the way they structured the infra.... This could be interesting to discuss and analyze....
Wip: Yes I think you are then agreeing with the PR and we could discuss this other item in a separate issue...
<bengo> +1 to merge
w3c/did-resolution#164
markus_sabadello: yes this came out of a discussion of another issue related to the created metadata...
markus_sabadello: I realized that the metadata items needed to re-organized....
markus_sabadello: They are mainly editorial and re-organization changes...
w3c/did-resolution#165
Add OpenAPI definition as an informative resource.
markus_sabadello: Yes this PR indicates that the Open API reference is informative....
Wip: Yes please review folks
w3c/did-resolution#167
markus_sabadello: Yes it a simple one. We discuss that https binding can also be local...
DID Resolution Issue Processing
<Wip> https://
w3c/did-resolution#13
Validate signatures/proofs of DID Document #13
markus_sabadello: This is related to trust in the resolution process and architectures.... I am planning to address this with an upcoming PR...
Wip: Could you please link this to ther other issues that it is related to?
<Zakim> JoeAndrieu, you wanted to ask isn't it the resolver result that should be signed? VDR proofs might be in metadata
JoeAndrieu: I think proofs are not ended documents....
JoeAndrieu: This seems to be looking for a proof where there isn't one...
<Zakim> bengo, you wanted to ask markus: why would this be in did-resolution vs a did method or trait specification? and to ask: are did documents non conformant if they have properties other than what is in DID-Core spec?
Wip: No...
bengo: Why does this need to be did-resolution instead of did-traits?
markus_sabadello: Yes the did-document is extensible. Also like Joe said proofs can be added by the resolver....
markus_sabadello: In the did-core spec we have a note about signature of did documents...
<Zakim> JoeAndrieu, you wanted to mention non-standardized properties are ok, just not standardized
markus_sabadello: So perhaps yes related to did-core, but still there is some relationship with did-resolution architecture...
<bengo> It does seem like some value a resolver could add is, optionally, detect proofs in did doc or resolution result and be like: "some proofs were detected the resolver thinks it knows how to verify them and it tried and was not able to verify the proof"
Wip: Yes I no there are not standardized properties, we should speak informatively to some of these properties....
Wip: We cannot be prescriptive of what did-methods should do... but we still have some informative guidance...
w3c/did-resolution#131
Add examples to illustrate different DID Resolution Architectures #131
Wip: Would someone be interested in taking this one on?
<Zakim> JoeAndrieu, you wanted to take that on
JoeAndrieu: I am happy to take this one. But would like to have some collaborators...
Wip: Yes this could be interesting, and also have some conversations around resolvers...
<Wip> w3c/
Complete threat modelling analysis for different DID Resolution architectures #132
Wip: Where should the threat modelling analysis live?
JoeAndrieu: The security group is looking to get all W3C specs to have a threat model analysis.... This could still be a separate document depending on how long it is...
w3c/did-resolution#149
Add Security Consideration about turning caching off #149
Wip: Perhaps Ben you can take a shot at this?
bengo: If it just adding a security consideration then I can take this on...