00:42:52 RRSAgent has joined #did 00:42:56 logging to https://www.w3.org/2025/11/11-did-irc 00:42:56 Zakim has joined #did 00:43:03 Wip has changed the topic to: DID WG 2025-11-11 https://www.w3.org/events/meetings/5918a72d-0c77-4257-88c2-fa2ce51e382e/ 00:43:53 Chair: Wip 00:44:24 Meeting: Decentralized Identifier Working Group 00:47:50 agenda: https://www.w3.org/events/meetings/5918a72d-0c77-4257-88c2-fa2ce51e382e/ 00:50:25 JoeAndrieu has joined #did 00:51:11 present+ 00:51:14 present+ 00:51:18 manu_ has joined #did 00:51:41 dariusk has joined #did 00:51:41 jay has joined #did 00:51:42 present+ 00:51:42 present+ 00:51:44 present+ 00:51:50 present+ 00:52:02 Wip: Welcome to the W3C DID WG meeting at TPAC 00:52:05 regrets+ 00:52:06 scribe+ 00:52:16 (unless summoned from RDF&SPARQL) 00:52:39 Wip: We are going to go over logistics, room, wifi, link to slides, etc. 00:52:58 dezell has joined #did 00:53:07 present+ David_Ezell 00:53:10 https://docs.google.com/presentation/d/1-VO1DQlTLcC4a19wuMUOU9U1HMp0Dvs0th8uMF2uNHA/edit?slide=id.g2a8584cc70_0_0#slide=id.g2a8584cc70_0_0 00:53:18 Wip: Slides are above ^ 00:53:21 phila has joined #did 00:53:24 identitywoman has joined #did 00:53:31 elena has joined #did 00:53:31 present+ 00:53:42 Wip: We need to pick scribes 00:54:08 pchampin -- does DID meeting span midnight? (RRSAgent should be informed.) 00:55:03 rrsagent, this meeting spans midnight 00:57:11 present+ 00:57:46 kmoon has joined #did 00:58:36 scribe+ 00:58:44 scribe- 00:59:42 Wip: Formal meeting of WG, participants only, observers cannot make substantial contribution. 00:59:51 JennieM has joined #did 01:00:12 JoeAndrieu: How can people who show up but aren't members participate? 01:00:21 present+ 01:00:35 Wip: We welcome discussion but it's up to the WG to decide how to integrate the comments. 01:05:19 hsano2 has joined #did 01:06:29 JoeAndrieu has joined #did 01:07:25 markus_sabadello has joined #did 01:11:10 dmitriz has joined #did 01:11:34 Wip: Open invitation for dinner RSVPs 01:13:32 Wip: The agenda is kind of flexible and can be evolved if there are things that need discussing. My sense was we are coming towards the end of this WG, and DID resolution has outstanding issues I would like to see discussed. We'll see how the day evolves and if there are specific things that need discussion we can set time for it. At half past 11 01:13:32 we are discussing DID resolution vs DID URL dereferencing. 01:14:09 Wip: Someone from the AB will speak at some point today as well, which we'll fit in. 01:15:38 manu: Early history of DIDs. We've been doing DIDs for almost a decade at this point. Starting arround 2014 there was a Decentralized Hashtables for the Web published. 01:15:52 The timeline is here: https://w3c.github.io/did/diagrams/timeline.html 01:16:16 manu: This was during the blockchain boom and discussion at IIW followed by Rebooting the Web of Trust there was a lot of discussion around decentralized identity 01:17:06 manu: Around 2016 is when US DHS started awarding the first blockchain identity r&d contracts. W3C DID spec in 2017, incubated for several years 01:17:51 manu: Around 2019 we started thinking about the WG at W3C. Able to charter the first W3C DID WG and publish a first working draft in 2020. 01:18:34 manu: Candidate recommendation in 2021, proposed recommendations in July 2021, then 1 year to resolve Formal Objections. Eventually resolved (overridden), around us not defining a DID method 01:19:00 manu: At that time there were 120+ DID methods proposed and it was too difficult to pick one. 01:19:32 manu: In 2023 did:plc launched, and a number of other orgs were using other methods like did:key, did:web, did:jwk 01:20:13 manu: in 2024 Bluesky adoption grew and we are currently at 40M DIDs on Bluesky. CA DMV wallet has about 3M DIDs issued through the wallet itself 01:21:25 manu: 220 DID methods registered at this point. Both a blessing and a curse for this group. The criticism is there are too many and you can't focus the market. Part of the strategy in the beginning was we don't know what the right methods should be, so waiting has given us a view into the all the different types of DID methods that could exist 01:22:17 manu: DID as a term came from a spec originally around 2014, "Decentralized Hashtable for the Web" spec, and "decentralized identifier" was defined there with the DID acronym 01:22:47 manu: The idea is to have an identifier that was fully under control of an individual and a document associated with cryptographic keys etc also owned by the individual 01:24:34 q? 01:24:36 manu: First requirement for a DID is it is permanent and persistent identifier that never needs to change. An identifier could theoretically last decades. Second requirement is the DID needs to be resolvable so you can look it up and get metadata like cryptographic keys. Third the identifier itself needs to be cryptographically verifiable. As 01:24:36 opposed to a national ID number for example, where there is no proof you have your national ID number without checking with a registry. The fourth requirement is that it is decentralized with no central authority. 01:25:39 manu: There are many DIDs that have required centralized registries. There was much objection but eventually the group allowed them to register. To this day it is a controversial topic. There are proposals that did:web is not decentralized and so on. But those are the four things that drove the specification. 01:26:07 manu: A DID is a URN scheme, urn scheme identifier, a namespace, and a namespace specific string. 01:26:35 manu: The scheme is did:, the DID method is the next part, and the third is the DID method specific string 01:27:03 manu: DID primer here: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/did-primer-extended.md 01:27:44 manu: Fundamentally we created DIDs because we wanted people to own their identifiers. A DID is a digital control point that asserts control over information. 01:28:17 manu: People use email addresses as a digital identifier. People lease their email from a provider like gmail, or for smaller providers there's domain names that can be taken away. 01:28:56 manu: You don't own your phone number. The provider does. That's another control point. It is problematic when you have your phone number or email taken away from you. 01:29:46 Yasu has joined #did 01:30:06 manu: DIDs change the control point. Instead of the DID being on some server owned by a service provider or network, a DID is on your device or ideally spread between your devices. In the most ideal case, you own the identifier, and that is nation-state-actor resistant cryptography 01:31:09 manu: The other important thing is that because people can lose keys and devices, we need to make sure you can rotate keys without the DID changing. The DID is a stable identifier, but if you lose your phone or your laptop breaks, and so on, there is a way to rotate those keys so you can continue to control the DID and just the keys change. 01:31:42 manu: We are trying to democratize cryptography so everyone can use it. Individuals won't be exposed to DIDs directly and most won't know they are there. But it's there and important to give you protection. 01:33:13 manu: Today DIDs are in production and have been for a long time, at least in internet time. Bluesky uses did:plc and is the biggest deployer of DIDs. The group was very sad how super centralized their DID was. did:plc started out meaning "placeholder" but they changed it to "public ledger of credentials" and they are spinning it out into a 01:33:13 decentralized nonprofit. 40M DIDs active. 01:34:14 manu: TruAge uses did:key, we use DIDs on TruAge in age verification credentials, ephemeral DIDs for now. Several million in TruAge, but potential for 50M+ age checks every day 01:35:21 manu: California DMV uses DIDs, went live 18 months ago, 3M people walking around with the CA DMV app, which uses did:jwk and did:web in the app. CA DMV has put verifiable credentials on the back of every single drivers license and ID card, rolling out to 34M people in CA over time 01:36:13 manu: Switchchord is an example of a smaller org. They create services for music publishers and song writers to route data into catalog management systems 01:37:42 manu: Taiwan is doing digital ID pilot testing, some movement from Bhutan National Digital Identity 01:38:14 q+ 01:38:28 https://www.bhutanndi.com/article/bhutan-adopts-ethereum-for-national-identity-a-new-chapter-in-digital-sovereignty_2d0c7ec2-5605-4c42-b258-bd9361ae8878 01:39:32 markus_sabadello: In South Korea there will be regulation that requires digital product passports (DPP) for certain types of products. Based on a set of UNTP DPP specifications and focused on interop between South Korea and EU etc 01:40:14 phila: There will be a breakout regarding UNTP and verifiable credentials on Thu 01:42:11 markus_sabadello: Spatial Web Foundation is an ambitious IEEE standard designed a number of building blocks including a data model called HSML and protocol HSTP as a generic universal data model, kind of like the semantic web for three dimensional space. Imagine linked data for 3D spatial information, working on use cases for supply chain, smart 01:42:11 cities, energy, etc. There's a POC involving a lunar lander collecting data and feeding into a spatial web concept. They are using DID methods to discover service endpoints 01:44:14 manu: It's great to see so much uptake on DID methods, but it's a struggle to see so many people creating their own DID methods instead of using existing ones. 01:44:39 https://github.com/microsoft/did-x509 01:45:16 phila has joined #did 01:45:18 Wip: I'm going to review where we are at as a WG in terms of getting to Candidate Recommendation and wrapping up. The mission is to maintain the DID Specification, and second and primary focus is to make a 1.0 specification for DID resolution and DID URL dereferencing 01:45:56 Wip: We have notes that we choose to work on. DID Specification Registries includes transitioning it from a WG Note to a W3C Registry 01:46:54 q? 01:46:55 Wip: There is the DID Method Rubric which we intend to transition to a Registry, and some other Notes that aren't working on actively but have worked on in the past 01:47:16 Wip: Class 4 level changes to the DID specification are out of scope fo rthe WG 01:47:23 q- markus_sabadello 01:48:41 q+ 01:48:43 Wip: We work on a spec, create a public working draft, then we move to Candidate Recommendation which involves horizontal review from TAG and others. CRD is a Candidate Recommendation Draft; CRS is a Candidate Recommendation Snapshot. Snapshots capture normative changes in Drafts 01:49:05 ack manu_ 01:49:07 Wip: Finally there's the approval/recommendation process 01:50:48 Wip: We are chartered as a WG until April 2026. Two recommendation-track specs are DID v1.1 and DID Resolution v1.0. Test suite and implementation report is a deliverable. And possibly W3C Registries for Rubric and Extensions 01:51:21 Wip: We can work on the registries but need to prioritize the specs. We can also recharter, and our staff contact will talk to us about charter extension possibility 01:52:01 q+ to ask about cr for registries 01:52:10 Wip: It's November now and we are not quite in Candidate Recommendation but we have completed horizontal review. We have a Candidate Rec document but not entered yet. Ten open issues on spec but only one that needs active discussion 01:53:07 elena has joined #did 01:53:34 ack JoeAndrieu 01:53:34 JoeAndrieu, you wanted to ask about cr for registries 01:53:35 Wip: DID resolution is further behind than DID v1.1. We are hoping for a CR1 in Feb 2026. We've asked for horizontal review and today we are hoping to address horizontal review comments, particularly from TAG. We are likely going to need an extension 01:54:05 JoeAndrieu: I know Notes don't go through a review process. Are Registries something that need AC approval? 01:54:36 (?): Registries might be more like a Note but I have to check 01:55:47 Wip: For DID Resolution v1.0 we have 50 open issues. 8 need PR review; 8 are ready for PR and should be looked at and the work assigned. 30+ need processing/triage. We are also awaiting privacy&security review, and accessibility review 01:56:28 q+ 01:56:34 Wip: Pierre-Antoine will discuss the process for extending the WG charter so we can have time to meet our goals. 01:56:43 ack phila 01:56:45 There are only 5 Draft Registries, and no Candidate Registries or Registries yet https://www.w3.org/TR/?filter-tr-name=&status%5B%5D=dry&status%5B%5D=cry&status%5B%5D=ry 01:57:05 phila: Your charter extension is a lot easier if you're in CR than if you're not. 01:57:51 Brent: setting up a registry and getting documents in place is similar to the Rec track, but then updating after that is much simpler. Registry track is a lot like regular approval just without IPR review 01:58:06 JoeAndrieu: I would like to submit we start work on the Registry process 01:58:20 Brent: I would like to hear how it goes because not many people have done the Registry process 01:59:34 scribe- 02:08:15 JoeAndrieu has joined #did 02:17:13 JoeAndrieu has joined #did 02:23:08 Wip has joined #did 02:28:04 JoeAndrieu has joined #did 02:30:57 JoeAndrieu has joined #did 02:31:38 IdentityWoman has joined #did 02:31:49 scribe+ 02:33:17 wip: discussion DID resolution URL deferencing - do we need this? 02:33:25 https://github.com/w3c/did-resolution/issues/228 02:33:26 ... Issue 228 02:33:33 q+ to speak after intro with a proposal 02:33:34 dariusk has joined #did 02:33:54 ... currently language is we resolve DIDs - my understsanding everything else is dereferenced 02:34:19 ... issue was raised by jeffery - we say "resolve" but this is wrong because it is applying to the resolution process. 02:34:34 ... raised by JoeAndrieu and @ someone 02:34:52 ... this is a URL with a version time parameter - where does it apply? 02:35:00 I have made the request to generate https://www.w3.org/2025/11/11-did-minutes.html TallTed 02:35:09 q+ 02:35:10 ack JoeAndrieu 02:35:10 JoeAndrieu, you wanted to speak after intro with a proposal 02:35:16 ... should be the version time of the resource? 02:35:23 q+ 02:35:38 JoeAndrieu error thinking resolution only needs a DID - so we don't have a quiry parameters in the DID URL. 02:35:53 PZ has joined #did 02:35:53 ... if you are dereferencing you are resolving DID URL 02:36:23 ... it clarifies you do need to handle these parameters - it is about resolution and not the resources. 02:36:37 s/decentralized nonprofit. 40M/... decentralized nonprofit. 40M/ 02:36:48 ack manu_ 02:36:52 s/opposed to a national ID number/... opposed to a national ID number/ 02:36:55 phila has joined #did 02:36:58 ... we set this up because we wanted parameters. 02:37:09 q+ 02:37:16 s/we are discussing DID resolution vs DID URL dereferencing/... we are discussing DID resolution vs DID URL dereferencing/ 02:37:19 @manu: not that different - lets just make the fix. 02:37:37 ack markus_sabadello 02:37:39 s/cities, energy, etc. There's/... cities, energy, etc. There's/ 02:37:49 q+ scurran 02:37:54 manu: we have to make right did resolution if are going to get right DID URL. 02:37:54 swcurran has joined #did 02:38:02 present+ 02:38:05 I have made the request to generate https://www.w3.org/2025/11/11-did-minutes.html TallTed 02:38:24 q+ 02:38:33 markus_sabadello: I agree with Joe these parameters - version time apply to did resolution. 02:38:38 ack JoeAndrieu 02:38:46 q 02:38:52 q+ 02:39:27 q+ 02:39:28 q+ 02:39:28 ack swcurran] 02:39:32 q- scurran 02:39:35 JoeAndrieu: at first I was going to point out one of the differences with URL do not to did resolution - URL Does send paramters based on the sceheme - (mailto vs. URL). query parameters don't get passed through DNS the way this is working. 02:39:54 swcurran: confusing that there are two terms and two algorythms. 02:39:57 q+ to note that "going to DNS" is different from "going to web server" -- "what's doing the resolution?" 02:40:29 csarven has joined #did 02:40:52 ... we have certain query parameters - version time and version ID other parameters that might also affect returnign of DID doc. Why make separation and make two different algorithms. 02:40:58 present+ 02:41:10 present+ 02:41:21 ... the way I termed in that PR - use the parameters that impact the return of that DID document 02:41:45 ... i think it is confusing that there are two terms that mean two different things when they are resolved. 02:41:46 ack Wip 02:42:05 dezell has joined #did 02:42:25 Wip: Put self on que to talk about what is in the document. I think the distinction is about 02:42:38 swcurran: there are four different things that can be returned. 02:43:28 wip: Example I show of de-referencing - in slides on slide 58 02:43:43 JoeAndrieu: we also have to talk about to resolve. 02:43:45 q+ 02:44:03 q- 02:44:27 kmoon has joined #did 02:44:33 Wip: with DID URL you go to de-referencing aldogrithm and then passes through to resolution algorithm. 02:44:37 ack manu_ 02:44:37 manu_, you wanted to note that "going to DNS" is different from "going to web server" -- "what's doing the resolution?" 02:44:46 Wip: don't know what we do if we do want to make a change. 02:45:15 q+ to speak to clarity 02:47:30 q+ 02:47:30 manu: I'm confused about what we are talking about - stephen you see there are 4 differnet outcomes - what are we trying to solve right now. 02:47:30 ... not hill worth dying on - nothing wrong with spec and not hill worth dying on. 02:47:30 q+ 02:47:44 ack swcurran 02:47:44 swcurran: seems to be objection the fact that I pulled in parameters into dereferencing - didn't make sense until difference between "resolution" and "dereferencing" - I found I was breaking things. 02:54:48 ack markus_sabadello 02:54:48 ... when we talk about dereferencing as a separate thing - parameters happen at dereferencing and at other times. 02:54:48 q+ 02:54:52 markus_sabadello: you pointed out an important step in the algorythm. - resolution to the resolve function. 02:54:52 ...i wrote most of this so I don't think anything is broken 02:54:52 ack JoeAndrieu 02:54:52 JoeAndrieu, you wanted to speak to clarity 02:54:52 Wip: we have 10 min left. swcurran what is the fix? 02:54:52 JoeAndrieu: I think the solution is the editorial explaination 02:54:52 ... spec has failed to communicate - we need to talk about the step before resolution 02:54:52 ack phila 02:54:52 ... editorial change we could explain better 02:54:52 phila: look up and - can mean dereference, or resolution 02:54:52 q? 02:54:52 ack swcurran 02:54:52 ... two Japanese TPACs ago we were in Saporo spacial data on the web - is this data about the mountain.. They don't care get over it. 02:54:52 swcurran: I apprecaite that comment I think you are probably right. 02:54:52 ... I think it causes confusion to have two terms and two algorythms. There should be space for extensions that allow for other did resolution parameters. We had one at DIDWEBVH and we needed it and for it to be done correctly it had to go in to that Did resolution section. 02:54:52 q+ 02:54:52 ack JoeAndrieu 02:54:52 @wip: thanks Stephen - hearing editorial work to make this clearer in the spec. I think jeffery in a number of issues raised - also raised that maybe we just use one term - could use some clarification. 02:54:52 JoeAndrieu: I could make some headway - but I have to get through the threat model for this document. 02:54:52 ... could get something simpler and easier to understand. 02:54:52 Wip: I think we should rais an issue and track that. 02:54:52 ... editorial clarification 02:54:52 q+ 02:54:58 ...markus do we have a way for did resolution to be processed with this algorythm. 02:54:58 q+ to say "did-method-specific" 02:54:58 ack 02:54:58 markus_sabadello: there are some resolution options that have some issues for resolution. 03:05:18 RRSAgent has joined #did 03:05:23 logging to https://www.w3.org/2025/11/11-did-irc 03:05:23 ack JoeAndrieu 03:05:23 Wip: it is in the resolution options. i have raised this before with markus we do have muliple format. 03:05:41 JoeAndrieu: i think it is must or "error" I think this is content negotiation HTTP. 03:06:00 JoeAndrieu: I think if it can't use this representation then it should say error 03:06:51 @wip: I think the change that joe is proposing is the did resolution accept is Must use this value or through an error. 03:07:00 q? 03:07:13 JoeAndrieu: Grammar should be Must/either 03:07:20 Wip: Markus? 03:07:38 markus_sabadello: I think there is another open issue on this DID resolution behavior - http header. 03:07:52 q+ 03:08:07 @wip: can we label this ready for PR 03:08:10 ack csarven 03:08:20 multiple people: yes. 03:09:34 csarven: the issue with me is it is unclear if there is an accept header and the response there is a content type - the way this reasons they must use this value. if I send a request header with X and it comes back with Y - why am I required to process Y. 03:09:42 q+ to ask about multiple options in parameter 03:09:58 wip: either we are going to require they match or we through an error. 03:10:11 ack JoeAndrieu 03:10:11 JoeAndrieu, you wanted to ask about multiple options in parameter 03:10:14 I have made the request to generate https://www.w3.org/2025/11/11-did-minutes.html TallTed 03:10:15 csarven: I don't agree with that. 03:10:24 q+ 03:10:31 csarven: they respond with something - it is their option to process or not. 03:10:36 ack manu_ 03:10:49 JoeAndrieu: the caller should be the decider 03:10:53 csarven: I Think HTTP works this way. 03:11:06 csarven: it says if you request X you have to process Y. 03:11:11 JoeAndrieu: I don't get 03:11:30 csarven: it is up to the requestor to decided if they process or not. 03:12:23 manu: scarven is right it is not as clear as we thought 03:12:26 q+ 03:12:33 See https://github.com/w3c/did-resolution/issues/116 03:12:38 q+ 03:12:46 s/scarven/csarven 03:12:48 ... you can say your preferences - what you want. 03:13:13 manu: we are not clear if we are following HTTP accept header semantics are really complicated 03:14:23 ... are we accepting a really concrete media type - because there is only one concrete media type - but then we are basically saying someone is going to get confused this works like an http accept header. WE need to clarify if ware using htTP accept header semantics - if we are not doign that it becames easier to zero out. if we do that we are 03:14:23 breaking compatability with HTTP and how it works. 03:15:01 s/breaking compatibility/... breaking compatibility 03:15:10 ack JoeAndrieu 03:15:11 ... we are going to do our best job to return - they are going to return did-doc or not. You must use this value to determine content type. Right now we say if such a representation is supported or avaliabiiltly 03:15:13 q+ 03:16:06 q+ 03:16:06 q+ preference vs. 'accepting' the 'accept' field 03:16:07 ack markus_sabadello 03:16:08 JoeAndrieu: we just have one normative representaiton we will have other representations that resolvers will ant to produce - I wanted to put my self on teh que can I specify multiple media types - jSON, CBOR - do we have ability to say comma something else or a * . 03:16:35 q+ csarven 03:16:39 q- preference 03:16:40 q- vs. 03:16:42 q? 03:16:44 q- 'accepting' 03:16:45 q- the 03:16:48 q- 'accept' 03:16:51 q- field 03:17:42 markus_sabadello: at the moment the accept option it works the way manu described it - expressing a media typee. it is about accepting header - resolution option accept header. For me personally either way would be fine. I am leaning more changing to be aligned with http header. 03:17:46 ack Wip 03:18:34 q+ 03:18:39 q- 03:18:50 Wip: speaking ot this issue in particular. I think this conversation has helped me understand - it is fine as it is now. must return as a conformat document. You should be able to convert. 03:19:23 ack manu_ 03:19:28 ... is it returning a serialized document. it addresses normative statement - the issue of if we want to use HTTP header is wider then this issue. 03:19:39 how would you return something that isn't serialized? 03:19:59 ack csarven 03:20:05 @manu: I agree with what markus said use HTTP serialization - if we follow HTTP semantics for waht is sent and reciveed we should do that. 03:20:57 csarven: looking at spec and comment - it is making more sense. It make disciction of accepting header. saying accept field is "optional" then why 03:21:09 ... rules out errroring around accept field. 03:21:40 ... if you are capable of providing this the server will provide this and go along with it - if you can't it will give you back something and say I don't have a representation and return an error. 03:22:18 Wip: ok great - to summarize before we move on. We are able to ready this to PR - I think changes want we want to model on accept headers on HTTP - 03:22:22 JoeAndrieu: so reference that in this issue to connect the.m 03:23:03 Wip: if we are going to reply to jeffery we think this language is translatable to application / did. 03:23:15 Wip: does everyone agree we don't need changes to the spec 03:23:32 JoeAndrieu: I think it might be nul - we need this get out of jail free card 03:23:43 q+ 03:23:44 ack Wip 03:23:50 JoeAndrieu: this can not turn into a did document - 03:24:05 Wip: if the did document is NUL then it must be an error 03:24:55 JoeAndrieu: they have to error out if they can provide a transformable DIDdoc 03:25:29 JoeAndrieu: Resolver should return something. 03:25:43 JoeAndrieu: Request and accept 03:26:26 csarven: if you are capable of providing a response - is to express a preference. within HTTP both routes are valid - if there are errors there are coresponding error codes. You can. 03:26:53 JoeAndrieu: if the server can't find the resource I'm asking for - it returns a 404. I think that is the use-case I am talking about. 03:27:02 csarven: that works 03:27:25 subtopic: https://github.com/w3c/did-resolution/issues/116 03:27:25 @wip: we talk model accept headers we take that on we are ready for model accept headers. 03:27:39 markus_sabadello: I already assigned 03:27:49 subtopic: https://github.com/w3c/did-resolution/issues/235 03:28:23 q+ 03:28:37 ack manu_ 03:28:42 Wip: issue 235 this is about confusing proof property in metadata returned by DID resolver. 03:28:58 manu: I think markus' langauge is fine 03:29:04 Wip: can we assign to anyone. 03:29:12 wip: I can do this 03:29:17 ... moving on 03:29:30 subtopic: https://github.com/w3c/did-resolution/issues/236 03:29:50 q+ 03:29:55 ack manu_ 03:29:57 wip: jeffery is saying we don't need this text - we don't say how to define did data registry. 03:30:02 Manu: + 1 03:30:11 wip: anyone willing to take this one 03:30:15 @manu: I can do it 03:30:33 manu: I can do it 03:30:41 subtopic: https://github.com/w3c/did-resolution/issues/238 03:30:59 Wip: number 238 - currently there is no clear way to handle did resolution in the spec 03:31:18 markus_sabadello: yes I can take this on 03:31:31 s/that works/that works for 406 as no representation that would be acceptable to the UA, whereas 404 no representation found 03:32:00 JoeAndrieu: I don't know what they mean - properties defined in extensions registry. Nothing in did document called .. we should add did method specific properties. 03:32:25 manu: can we say iterate over all properties in the DID document 03:32:42 manu: then we don't have to talk about extensions - then just going through everything in DID Document. 03:33:22 q+ 03:33:29 ack JoeAndrieu 03:33:52 JoeAndrieu: where in the spec is that you have to process all these things. Seems weird that did document resolution have to do things. 03:34:43 manu: this is part of the expand URLs algorithm you want to go into every object in the did document and expand the URLs 03:34:56 subtopic: https://github.com/w3c/did-resolution/issues/232 03:35:18 q+ 03:35:26 wip: can we avoid term difinition duplication across DID specs - we can just point to DID core terminology 03:35:32 ack manu_ 03:36:04 Wip: if we can to this easily 03:36:17 error that was manu talking 03:36:27 manu: yes we can to this easily 03:36:56 wip: to address this we need to clean up all the terms duplicated - 03:37:08 manu: its very easy to do...explained how 03:37:32 manu: will share link to how to do. 03:37:45 Yasu has joined #DID 03:37:53 Wip: goal is to cover all the issues today and discuss them. 03:37:58 subtopic: https://github.com/w3c/did-resolution/issues/233 03:38:24 ... moving on - we have a yellow flag - we use term "match" and what does this term mean? 03:39:23 Wip: I linked to wrong thing section 4 - must match...what does it mean? we should be more clear. I think we state string equivalent. 03:39:43 Wip: I will take this... 03:39:47 q+ 03:40:07 ack csarven 03:40:39 q+ 03:40:53 csarven: question of whatever spec you are already covering this - is there a place URI comparisions are described - to get to the point of determining base. for example upper-case = lower case equivalent? 03:40:57 ack manu_ 03:41:02 csarven: need to refer to place. 03:41:25 q+ 03:41:33 ack JoeAndrieu 03:41:36 manu: we have ABNF for did syntax - we do not have normalization rules for url if quiry parameters on in different orders - is this the same URL 03:41:57 JoeAndrieu: query about DID not DID URL (has parameters) 03:42:11 JoeAndrieu: method could create this problem for us 03:42:37 JoeAndrieu: Did method specific component can have upper and lower case. 03:42:59 manu: after we get into identifier - it is up to did method 03:43:28 subtopic: https://github.com/w3c/did-resolution/issues/224 03:43:51 wip: we should be referencing DID 1.1 throughout. 03:44:05 q+ 03:44:10 ack manu_ 03:44:10 JoeAndrieu: I don't know what that means. What do I need to be practical to be backwards compatable with 1.o 03:44:22 manu: in theory we don't need to do anything. 03:44:43 q+ 03:45:00 manu: didn't remove anything - just added. now we have full test stuite for 1.1 - 74 did methods the are all backwards compatable with 1.0 - I don't think anyone needs to think about it. 03:45:27 JoeAndrieu: no requirement to be conformat to 1.0 03:46:01 We <3 easy issues 03:48:03 subtopic: https://github.com/w3c/did-resolution/issues/225 03:48:32 Wip: would prefer did resolution is more grounded an technical. 03:48:44 wip: did resolution is just a way to resolve dids and did documents 03:49:08 it was agreed it should be toned down 03:49:18 wip: anyone want to volunteer? 03:49:20 moving on 03:49:26 subtopic: https://github.com/w3c/did-resolution/issues/226 03:49:39 JoeAndrieu: can we tie that to the other issue that I'm doing... 03:50:08 wip: yes 03:50:26 wip: but isn't about issue we haven't created yet 03:50:30 JoeAndrieu: yes. 03:51:38 wip: one more... 03:51:53 subtopic: https://github.com/w3c/did-resolution/issues/229 03:52:30 q+ 03:52:32 q+ 03:52:38 wip: we have discussed this - I want to clarify this is about hash link when we discuss this before we caviat this the base parameter is non-normative. Every single did parameter is optional in the spec 03:52:54 ack JoeAndrieu 03:53:07 wip: we explicitly this is a non-normative parameter so what do we say 03:53:39