Meeting minutes
Wip: Welcome to the W3C DID WG meeting at TPAC
<TallTed> (unless summoned from RDF&SPARQL)
Wip: We are going to go over logistics, room, wifi, link to slides, etc.
Wip: Slides are above ^
Wip: We need to pick scribes
<TallTed> pchampin -- does DID meeting span midnight? (RRSAgent should be informed.)
Wip: Formal meeting of WG, participants only, observers cannot make substantial contribution.
JoeAndrieu: How can people who show up but aren't members participate?
Wip: We welcome discussion but it's up to the WG to decide how to integrate the comments.
Wip: Open invitation for dinner RSVPs
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
… we are discussing DID resolution vs DID URL dereferencing.
Wip: Someone from the AB will speak at some point today as well, which we'll fit in.
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.
<Wip> The timeline is here: https://
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
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
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.
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
manu: At that time there were 120+ DID methods proposed and it was too difficult to pick one.
manu: In 2023 did:plc launched, and a number of other orgs were using other methods like did:key, did:web, did:jwk
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
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
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
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
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
… 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.
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.
manu: A DID is a URN scheme, urn scheme identifier, a namespace, and a namespace specific string.
manu: The scheme is did:, the DID method is the next part, and the third is the DID method specific string
manu: DID primer here: https://
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.
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.
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.
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
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.
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.
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
… decentralized nonprofit. 40M DIDs active.
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
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
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
manu: Taiwan is doing digital ID pilot testing, some movement from Bhutan National Digital Identity
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
phila: There will be a breakout regarding UNTP and verifiable credentials on Thu
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
… 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
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.
<JoeAndrieu> microsoft/
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
Wip: We have notes that we choose to work on. DID Specification Registries includes transitioning it from a WG Note to a W3C Registry
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
Wip: Class 4 level changes to the DID specification are out of scope fo rthe WG
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
Wip: Finally there's the approval/recommendation process
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
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
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
<Zakim> JoeAndrieu, you wanted to ask about cr for registries
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
JoeAndrieu: I know Notes don't go through a review process. Are Registries something that need AC approval?
(?): Registries might be more like a Note but I have to check
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
Wip: Pierre-Antoine will discuss the process for extending the WG charter so we can have time to meet our goals.
<denkeni> There are only 5 Draft Registries, and no Candidate Registries or Registries yet https://
phila: Your charter extension is a lot easier if you're in CR than if you're not.
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
JoeAndrieu: I would like to submit we start work on the Registry process
Brent: I would like to hear how it goes because not many people have done the Registry process
wip: discussion DID resolution URL deferencing - do we need this?
<Wip> w3c/
wip: Issue 228
… currently language is we resolve DIDs - my understsanding everything else is dereferenced
… issue was raised by jeffery - we say "resolve" but this is wrong because it is applying to the resolution process.
… raised by JoeAndrieu and @ someone
… this is a URL with a version time parameter - where does it apply?
<Zakim> JoeAndrieu, you wanted to speak after intro with a proposal
wip: should be the version time of the resource?
JoeAndrieu error thinking resolution only needs a DID - so we don't have a quiry parameters in the DID URL.
… if you are dereferencing you are resolving DID URL
… it clarifies you do need to handle these parameters - it is about resolution and not the resources.
… we set this up because we wanted parameters.
@manu: not that different - lets just make the fix.
manu: we have to make right did resolution if are going to get right DID URL.
markus_sabadello: I agree with Joe these parameters - version time apply to did resolution.
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.
swcurran: confusing that there are two terms and two algorythms.
… 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.
… the way I termed in that PR - use the parameters that impact the return of that DID document
… i think it is confusing that there are two terms that mean two different things when they are resolved.
Wip: Put self on que to talk about what is in the document. I think the distinction is about
swcurran: there are four different things that can be returned.
wip: Example I show of de-referencing - in slides on slide 58
JoeAndrieu: we also have to talk about to resolve.
Wip: with DID URL you go to de-referencing aldogrithm and then passes through to resolution algorithm.
<Zakim> manu_, you wanted to note that "going to DNS" is different from "going to web server" -- "what's doing the resolution?"
Wip: don't know what we do if we do want to make a change.
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.
… not hill worth dying on - nothing wrong with spec and not hill worth dying on.
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.
… when we talk about dereferencing as a separate thing - parameters happen at dereferencing and at other times.
markus_sabadello: you pointed out an important step in the algorythm. - resolution to the resolve function.
… i wrote most of this so I don't think anything is broken
<Zakim> JoeAndrieu, you wanted to speak to clarity
Wip: we have 10 min left. swcurran what is the fix?
JoeAndrieu: I think the solution is the editorial explaination
… spec has failed to communicate - we need to talk about the step before resolution
… editorial change we could explain better
phila: look up and - can mean dereference, or resolution
… 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.
swcurran: I apprecaite that comment I think you are probably right.
… 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.
@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.
JoeAndrieu: I could make some headway - but I have to get through the threat model for this document.
… could get something simpler and easier to understand.
Wip: I think we should rais an issue and track that.
… editorial clarification
… markus do we have a way for did resolution to be processed with this algorythm.
<JoeAndrieu> ack
markus_sabadello: there are some resolution options that have some issues for resolution.
Wip: it is in the resolution options. i have raised this before with markus we do have muliple format.
JoeAndrieu: i think it is must or "error" I think this is content negotiation HTTP.
JoeAndrieu: I think if it can't use this representation then it should say error
@wip: I think the change that joe is proposing is the did resolution accept is Must use this value or through an error.
JoeAndrieu: Grammar should be Must/either
Wip: Markus?
markus_sabadello: I think there is another open issue on this DID resolution behavior - http header.
@wip: can we label this ready for PR
multiple people: yes.
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.
wip: either we are going to require they match or we through an error.
<Zakim> JoeAndrieu, you wanted to ask about multiple options in parameter
csarven: I don't agree with that.
csarven: they respond with something - it is their option to process or not.
JoeAndrieu: the caller should be the decider
csarven: I Think HTTP works this way.
csarven: it says if you request X you have to process Y.
JoeAndrieu: I don't get
csarven: it is up to the requestor to decided if they process or not.
manu: csarven is right it is not as clear as we thought
<markus_sabadello> See w3c/
manu: you can say your preferences - what you want.
manu: we are not clear if we are following HTTP accept header semantics are really complicated
… 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
breaking compatability with HTTP and how it works.
… 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
<TallTed> s/breaking compatibility/... breaking compatibility
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 * .
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.
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.
… 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.
<JoeAndrieu> how would you return something that isn't serialized?
@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.
csarven: looking at spec and comment - it is making more sense. It make disciction of accepting header. saying accept field is "optional" then why
… rules out errroring around accept field.
… 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.
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 -
JoeAndrieu: so reference that in this issue to connect the.m
Wip: if we are going to reply to jeffery we think this language is translatable to application / did.
Wip: does everyone agree we don't need changes to the spec
JoeAndrieu: I think it might be nul - we need this get out of jail free card
JoeAndrieu: this can not turn into a did document -
Wip: if the did document is NUL then it must be an error
JoeAndrieu: they have to error out if they can provide a transformable DIDdoc
JoeAndrieu: Resolver should return something.
JoeAndrieu: Request and accept
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.
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.
csarven: that works for 406 as no representation that would be acceptable to the UA, whereas 404 no representation found
w3c/did-resolution#116
@wip: we talk model accept headers we take that on we are ready for model accept headers.
markus_sabadello: I already assigned
w3c/did-resolution#235
Wip: issue 235 this is about confusing proof property in metadata returned by DID resolver.
manu: I think markus' langauge is fine
Wip: can we assign to anyone.
wip: I can do this
… moving on
w3c/did-resolution#236
wip: jeffery is saying we don't need this text - we don't say how to define did data registry.
Manu: + 1
wip: anyone willing to take this one
@manu: I can do it
manu: I can do it
w3c/did-resolution#238
Wip: number 238 - currently there is no clear way to handle did resolution in the spec
markus_sabadello: yes I can take this on
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.
manu: can we say iterate over all properties in the DID document
manu: then we don't have to talk about extensions - then just going through everything in DID Document.
JoeAndrieu: where in the spec is that you have to process all these things. Seems weird that did document resolution have to do things.
manu: this is part of the expand URLs algorithm you want to go into every object in the did document and expand the URLs
w3c/did-resolution#232
wip: can we avoid term difinition duplication across DID specs - we can just point to DID core terminology
Wip: if we can to this easily
error that was manu talking
manu: yes we can to this easily
wip: to address this we need to clean up all the terms duplicated -
manu: its very easy to do...explained how
manu: will share link to how to do.
Wip: goal is to cover all the issues today and discuss them.
w3c/did-resolution#233
Wip: moving on - we have a yellow flag - we use term "match" and what does this term mean?
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.
Wip: I will take this...
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?
csarven: need to refer to place.
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
JoeAndrieu: query about DID not DID URL (has parameters)
JoeAndrieu: method could create this problem for us
JoeAndrieu: Did method specific component can have upper and lower case.
manu: after we get into identifier - it is up to did method
w3c/did-resolution#224
wip: we should be referencing DID 1.1 throughout.
JoeAndrieu: I don't know what that means. What do I need to be practical to be backwards compatable with 1.o
manu: in theory we don't need to do anything.
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.
JoeAndrieu: no requirement to be conformat to 1.0
We <3 easy issues
w3c/did-resolution#225
Wip: would prefer did resolution is more grounded an technical.
wip: did resolution is just a way to resolve dids and did documents
it was agreed it should be toned down
wip: anyone want to volunteer?
moving on
w3c/did-resolution#226
JoeAndrieu: can we tie that to the other issue that I'm doing...
wip: yes
wip: but isn't about issue we haven't created yet
JoeAndrieu: yes.
wip: one more...
w3c/did-resolution#229
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
wip: we explicitly this is a non-normative parameter so what do we say
JoeAndrieu: this is more about culture and style of W3C I don't have a problem referencing standards not by formal standards organization - so we can't reference bitcoin primatives - I don't know how we deal with this
manu: I should drop the parameter - I don't think we have the time to figure out hashlink... - I don't think any one is using it.
TallTed: I believe there is a way to cite and RFC draft from a rec but I would have to dig a lot to find it. I'm pretty sure a group I am involved with did it - given it was an optional parameter and no one was fighting to use it - no reason folks can't use it without in the spec.
manu: not fully baked - not implementations - not tests - lets cut it.
<TallTed> My original point was that "This parameter is non-normative" is nonsensical.
markus_sabadello: agree with feature found useful in conversations - this topic comes up - sometimes. Yes this exists as possibility. in practice it is not implemented
phila: you can refer to whatever you like - just don't make it "normative" "one way to do this might be to look at this document over here" just can't make it normative.
JoeAndrieu: As currently implemented our extensions registry gets around this - we have extensions not referenced anywhere
JoeAndrieu: move into extensions registry - optional - is it normative.
wip: this is good because there is another issue
wip: who wants to do this
manu: I will do this
wip: thank you everyone.
W3C Process Discussion
wip: Welcome back.
… Staring with W3C process with Elena
elena: Thanks for having us.
… one of the things we are prioritizing this year is remapping the process and clarifying where it needs clarifying
… So we are going around WGs and collecting feedback
… To take it back to process CG, which is chaired by Brent
… I do have a list of questions, but that might not be the best use to go through each and every one.
… First of all, how much do you know about process
… Are there any sort of ... how you would express your experience
manu: it's getting better
… it used to be much harder to do things
… Removal of proposed rec is good.
… The document has gotten clearer over the years.
… I do think the formal objection process has gotten overly complicated and time consuming
… So people are trying really hard to avoid formal objections, drawing out what might have been resolved quickly
… Downsides with current process. There is some cruft that might not get used as much.
… We ended up publishing FPWDs for things that maybe we wouldn't have
… Seems like parts of the process I think we should not go through that. Delete it from process.
… Revising a Recommendation is one of those things I think we might remove
… Another part that is a little more difficult is where the responsibile of staff ends and AC picks up.
… This is particularly true for chartering.
… It's only once you get to know staff that you learn how you might start a group or charter.
JoeAndrieu: You had a question --
elena: What has been the biggest issue so far?
JoeAndrieu: Creating a registry
JoeAndrieu: We are guessing to what the next steps for a registry. We just found out today that it needs to go through CR and AC approval. We are pretty significant bottleneck there.
elena: think of last 12 months, what has been the biggest process blocker.
<Zakim> JoeAndrieu, you wanted to mention charter authority
JoeAndrieu: I've been working with Simone on Threat Modelling -- coming down pipe, requirements to have threat model -- people don't know how to do that, writing guide to threat modelling, but it is a bottleneck.
JoeAndrieu: Wanted to echo Manu's concern, framing differently -- challenging that it's not AC members that write charters, it's usually elected representatives -- unless staff blesses charter, feel like thats an inappropriate responsibility.
JoeAndrieu: First issue of new process was replace Tim w/ Staff -- logo issue, same thing -- is the AC in charge or not, is it the staff in charge or not?
elena: What's the ideal solution?
JoeAndrieu: Any AC member should be able to propose a charter, with input from Staff, AC Members should be able to propose a charter.
elena: Might be out of scope for Process CG.
JoeAndrieu: I don't know where else it might get fixed -- AC needs to look at this, get it in front of them to hear if they agree/disagree.
elena: To the text and documentation itself? How do you feel about clarity?
JoeAndrieu: I tend to look at process only when needed.
JoeAndrieu: Working w/ W3C Process is transactional...
elena: Is that how most use the process?
JoeAndrieu: I don't know which section to look at...
manu: I think I've read the process top-to-bottom maybe 4 times inlast 10 years
… one of the problems with those who have been working with it over the last 10 years is that it changes rapidly
… So people in the group think the process is XYX, but things have changed
… Usually when we go and try and read it, but I don't think we come away not understanding what the process is.
manu: The result is I have to reread the document because of changes
elena: Interesting. How is it usually surface "oh, something has changed".
… Who brings that wisdom to the group
manu: it's usually members who are in other groups who have experienced the change
… I don't think that's a bad thing, but the great thing about the new process document is much more is written down.
<Zakim> JoeAndrieu, you wanted to about objection ambiguity
manu: The tribal knowledge is just much more about changes than about the details.
JoeAndrieu: One thing I ran into wrt. formal objection -- ambiguity about when to object and what you can object to -- this was under old process.. Ambiguous on how I should deal with issues Chairs were making. Others on staff had interpretation that was different.
elena: What about formal objections?
JoeAndrieu: I've had objections that we've been able to work through. For new DID Methods WG, I'm probably going to object. We have right social processes in place to discuss.
manu: To add to that... +1 to Joe. There are the right social processes to work through objections. But because the new objection process goes to council and all that stuff
… We are trying REALLY REALLY hard to avoid formal objections. Because we know its going to take it forever.
… The DID Rec formal objections took a year to get through, and that led to people leaving the work.
… So we go out of our way to avoid objections of any kind.
… Formal objections are very asymmetric. Easy to raise. Hard to address.
… not sure what the solution is other than streamline the council creation, but that's not ideal either
… We lose people. I'm certain with this objection, we're going to lose contributors.
elena: that sounds like a real and serious pain point
elena: we're wearing purple badges, so please engage and we'll be bringing all of this input back to the process CG.
… thanks for the input
manu: Thanks so much for the AB being proactive.
wip: lets look at rest of day
… There are maybe 10-12 issues I'd like to get discussion on. A couple PRs that don't need a lot of input.
… Then there are some test suite issues about normative statements that I don't think are testable or we should just remove.
… That's all I have. Joe had mentioned rubric? We can maybe talk about that at the end of the day
manu: I'd like to make sure we get through all of the issues and get the all to ready for PR or defer them to future.
wip: so lets start with issue processing
DID Resolution Issue Processing
joeandrieu: I think we may have already handled the Rubric update
wip: There are two issues from TAG review.
w3c/did-resolution#237
wip: This is similar to the "accept" discussion, but it is slightly different
this looks like a duplicate
pchampin: they do look the same, maybe we can combine
wip: this is saying it's a must.
joe: are you saying we're inconsistent?
wip: yep,
… the placement with MUST (DID REsolution algorithm 3.1) is a conflict with a SHOULD elsewhere (DID Resolution options)
wip: I agree with Manu, let's just remove this extra bit.
manu: maybe we can just stay silent since it's covered elsewhere
wip: ok
JoeAndrieu: +1 to deleting
wip: Anyone want to take it on?
[crickets]
wip: Ok. moving on.
w3c/did-resolution#230
wip: We discussed this. We don't define the read resolution anywhere.
… I think Joe commented that we don't have a concrete interface
… We also discussed changing this from Read to Resolve
… The argument to change it to resolve is that we don't define "Read" we define "Resolve"
… There is no read. It's either an old term.
JoeAndrieu: Its just an unfortunate and editorial change, the "Read" is in quotes as the CRUD read... it's not meant to be normative. We are talking about just resolution.
wip: Jeffrey is saying that there is no signature for this operation
JoeAndrieu: I don't think his point isn't that there is a formal signature on the endpoint, he proposes did resolution options as the interface. We had RESOLVE as a function that was defined... I think he does have a signature. DID Methods must support these contracts.
wip: Ok. Let's just update this from read to resolve.
denken: I just think it would be just easier to add in 7.2 method operations in DID v1.1, we just mention that the that Resolution is "Read"
wip: there are two ways to do this. Either change did core or change did-resolution
… seems we are more aligned with Resolve, although I note that Markus thinks of it as the DID Method defining "read" which is executed by the resolver
manu: I'm looking at the DID 1.1 spec and we use the resolve language
JoeAndrieu: Markus noted that the resolver is doing resolution, the DID Method spec is the thing that provides the read operation for the resolver.
wip: let's check in with Markus
… Great. That was all of Jeffrey's TAG issues
… Next, we'll work through the issues labelled "discuss"
w3c/did-resolution#244
<Wip> https://
JoeAndrieu: I think what he's talking about is that there is an option in the APi to have the resolver dereference for you -- that's the "client" -- it's not the resolution client... it's the local client.
JoeAndrieu: The caller to the resolver isn't returning an error to anyone.
wip: in step 9 we have a bunch of ways to dereference, 10 is what happens when those fail
manu: this should be rewritten to say if you make it this far, return an error
wip: I think we all agree something needs to change
manu: yeah, we should just rewrite that step 10. Maybe we can think of something now. [thinking... thinking...]
… Otherwise, the algorithm has resulted in an error
… And we can ask Markus to make the language better
[manu updates the issue]
w3c/did-resolution#240
wip: moving on
wip: I raised this. There's confusing language how we state the errors should be raised in the spec today.
… I misinterpreted how errors should happen (in my own work)
… Spec text states and error object should have "type set to invalidDID"
… We start with DID object set to "validDID"
… but the problem is that problem details has a different statement
… The values MUST be prepended. The type must be a URL
… I implented incorrectly, and the tests passed. And Markus also did the same, but it shouldn't.
… The error objects' type field MUST be a URL, but "validDID" isn't a URL
… We are linking to the problem details section, but as a developed, two of us independently failed to follow the link.
manu: So the change is just to have a full URL instead of "invalidDID"
wip: Ok. I will do this at some point.
[manu updates issue]
w3c/did-resolution#220
wip: there are three outstanding ISSUE markers in the spec we haven't talked about.
… Issue 38 seems good. But the two immediately after that, we should discuss to see if they matter
… First issue explain that DIDs are not necessarily globally resolvable. This is in security considerations sections
JoeAndrieu: I know that I've used the term, but we don't have clear definition of what globally resolveable is. If we want to use the term, we need to define it more clearly.
manu: can we just delete this?
joeandrieu: Agree. Also its not a security
JoeAndrieu: I think we could just delete it since it's off topic
joeandrieu: so it's kind of off topic.
wip: ok. let delete
… second one seems similar
… so we'll update the PR to remove the two issues, but is Issue 38 still useful
wip: Yes, it's important, but should it be in the spec as such.
manu: yeah, we can just track it in the repo.
JoeAndrieu: I think we should say something about this. There is strong narrative assumption that this is always resolveable -- but that might not be possible... but there might be good reasons to not give access to it
w3c/did-resolution#212
wip: I think there is already a PR for this
joeandrieu: in that PR it seems that the involved parties have come to agreement
wip: great. Then we can remove the "discuss" label
joeandrieu: are we going to merge it?
wip: I'm going to ask Markus
w3c/did-resolution#208
wip: Should we add a design goals section?
manu: Uh... no.
… we shouldn't do this. I don't think TAG requires it.
… The reason we sometimes put it in is because it's not clear what we are trying to do.
JoeAndrieu: Yes, +1, for VCs and DIDs, people wanted to know, for this spec, probably not.
manu: I don't think we need to add that unless someone is asking
w3c/did-resolution#203
wip: Madison is saying we need to define what we mean by datetime
… I was going to do that. So I looked at VCs and they don't normalize time
<pchampin> maybe https://
joeandrieu: I think its the 00:00:00 which doesn't make sense. We normalize to UTC, not UTC 00:00:00
manu: we do say it should be specified datetime timestamp with Z.
<Wip> VCDM Representing Time section: https://
manu: we had this section (VC 2.0 section 5.8 representing time) and it survived internationalization review, so let's just use that
wip: I think that's fine. I'm happy to use it. That is a change to this normative statement.
manu: don't say "normalize"
pchampin: A recent comment in RDF working group. The term "normalized" doesn't not appear. "Adjust" does. Adjust hours/min.
… seeing the hours minute seconds, I see Joe's confusion
… we can just replace normalized with "adjusted"
wip: so, should we reference the VCDM section?
manu: Yes, it has lots of language that matters.
manu: we shouldn't repeat this much spec text
wip: my concern is that we are not requiring it uses UTC.
joeandrieu: VCDM doesn't care about UTC, but we do.
manu: good point
joeandrieu: we want to profile the VCDM with like "You must represent tiem as in VCDM and it must be adjusted to UTC 0"
wip: In the DID resolution spec, we have different properties that define time, versionTime, created, lastUpdated, etc. I think Jeffrey suggested we define our representation once and refer to that throughout.
wip: it might be better to have a time property that we reference in each property that is "time"
manu: this is section 4.3?
manu: Yeah. I think that's the right thing. Specify a datetime format and in that section, refer to VCDM and adjusted to UTC without subsecond decimal precision
wip: and where does that go in the spec?
manu: it could go anywhere. define it before you use it
wip: ok. great.
wip: marking ready for PR
w3c/did-resolution#133
wip: Threat modeling
wip: This should be addressed when we have threat modeling
joeandrieu: it's going to block us from going into security review
JoeAndrieu: The bottleneck has been figuring out what security group wants out of a threat model. We are very close to being able to share something -- once that's done, in about 3 weeks, we have three diagrams that Markus has put together, we have local/remote proxy archiectures -- we might need to do diagrams with focused threats -- threats are relatively straightforwad to do once we have diagrams.
JoeAndrieu: There are four different types of threats we want to speak to, threats in threat model, in VCs we knew tampering was a threat -- that's why we have proofs. Next is implementation threats, key compromise, issuing VCs? Have to manage keys -- but implementers have to deal with it. External threats, which we don't know a away around, but people should be aware of.
JoeAndrieu: Dependency threats -- eg. DID Resolution relies on TCP/IP and HTTP -- specify some threats on TCP/IP dependencies -- and DNS -- spoofing DNS, and get false DID Document, that's a threat -- networking layer, router might decide Joe is a bad person and is sending me over there. That's part of wy it's taken longer, but getting close to something usable by the group.
wip: we have asked Simone for a security review.
JoeAndrieu: This "needs work" -- we are going to finish the threat modelling guide -- we'll need to facilitate some conversations, special topic calls, maybe this is "to be discussed" in context of threat modelling guide.
wip: we need to be in CR before April
… Maybe we should break to talk about that
manu: I'm really concerned about this timeline
… we wanted to get through our issues and be ready for PR
… And this looks like it might take another 3 months
wip: Maybe its worth talking with Simone to understand.
JoeAndrieu: I think it's negotiating with SING -- in order to go to CR, do we need threat model today -- conversation that staff needs to think about -- is it worth extending now because we need threat model, we are making good progress, maybe we put options to staff.
manu: I'm really concerned about what this does for our timeline.
JoeAndrieu: We should discuss this with Staff and have them provide guidance on what we do next.
wip: ok. we have a section that is security considerations
… the work is to review the DID architecture section and update the Privacy Consideration sections
JoeAndrieu: I do agree with where we should put these edits -- this is not put privacy/security issues in architecture section.
JoeAndrieu: Do we mention threat model in this issue?
Wip: No, we don't.
JoeAndrieu: Ok, let's keep threat model in another issue. Our intention is to complete threat model while we're in CR, not before.
ack
w3c/did-resolution#132
JoeAndrieu: Next steps are to talk w/ Simone / PA / Joe to figure out how to proceed
wip: next up threat modeling issue
JoeAndrieu: let's just tag this as "During CR"
wip: maybe PA can talk about getting an extension
wip: there remain 4 discuss issues and some related to test suite
manu: There is the DID threat model...
JoeAndrieu: I don't think that's usable
wip: that's it. To break
DIDWG Charter Extension
pchampin: We need a little more time. We can do an automatic charter extension, relatively straightforward since it's a team decision. Otherwise, we have to do rechartering -- requires more time and more effort, these are not exclusive.
pchampin: We are in a good position to request one charter extension to finalize specs. If we want to recharter, then we can use the extra time we have, waiting on others to review specs, maybe we can have bandwidth to discuss -- do we want to recharter? I'm working under assumption that we recharter... we could do two charter extensions of six months. Without rechartering, we could buy up to a year.
pchampin: Rechartering also means defining scope of next WG -- needs more discussion. We prefer to focus on specs themselves.
Wip: We expect that we'll be extending intiially.
manu_: +1 for 6 month charter extension
… We need to get these specs done. Time pressure helps with that
… Concerned about the additional time when the DID Methods WG starts up
… If we were going to recharter I would expect it to be a maintenance charter
… Not sure what else needs doing other than Rubric and the DID Extensions registry
JoeAndrieu: Turning DID methods into proper W3C registry would be worth doing
pchampin: Maintenance is not an official W3C Process, it's just a way to talk about charters that don't allow class 4 changes.
Wip: It makes sense -- we want to be in CR to ask for an extension, given charter ends in April, when do we need to ask for extension?
pchampin: A month ahead would be good.
Wip: DID Resolution should be to be done around Jan/Feb.
manu_: I am concerned about being able to get it done by Jan/Feb with the holidays coming up
JoeAndrieu: The path convesation could take 2-3 months
manu_: We could make the path stuff as at risks
… I am concerned about the number of people raising PRs and moving the spec forwards
… Need to start making significant strides in that direction
… Very aggresive to get into CR by March
… Very dependent on people writing PRs and moving the spec forward faster
… May be worth asking Markus if he has capcity to drive this forward given the deadline
… Might be worth giving W3C staff a heads up
markus_sabadello: For me it's hard to say how long it will take to get it done. A few weeks ago I thought we were almost done, but now there are new issues. A lot of issues are relatively easy to address, but there are 2-3 that might take a while.
markus_sabadello: +1 to what Manu said, getting the work done -- doing what I can, but also have other things to get done. We need more PRs raised.
Wip: Yes, tricky, don't have that big a WG with active contributors -- we can try our best, and staff will hopefully be open to discussion.
DID Resolution Issue Processing
w3c/did-resolution#131
Wip: What would need to happen in he spec to make this happen?
JoeAndrieu: I'm assigned to it. We pulled this into the threat modelling. Another possible response, illustrations of DID Resolution architectures that Markus put together.
JoeAndrieu: Haven't gotten to that yet. I think we can consider this part of threat mdel work, we can do this during CR.
JoeAndrieu: There is a version of illustration of different DID Resolution architectures that satisfy the issue.
markus_sabadello: Regarding DID Resolution architectures, there are diagrams in the document. Local resolvers and remote resolvers -- DID Methods can work in different ways -- intention of this issue was to add architectures for specific DID Methods.. What we have in spec is generic, but we can apply how generic model applies to did:key / did:web
markus_sabadello: This issue is option, if we don't do it it's not a big deal.
Wip: I'll leave it for "during CR" -- if we don't get to it, we can close the issue w/o consequences.
w3c/did-resolution#113
Wip: This says "A DID document is a reprsentation of information describing a DID subject" -- the language is in terminology section of DID Resolution and DID Core. We discussed that we would remove terminology from DID Resolution where they're already defined. If we want to update language, we'd have to do it in DID Core.
JoeAndrieu: I don't like this language -- Dave Longley is on the other side of the discussion of this -- Dave's coming from RDF perspective. Imagining DIDs as representing subjects gets us in trouble w/ GDPR, how long lived they are, how they're bound to you... You as an individual might have thousands of DIDs about actions that are momentarily about you. Privacy problem, aggregation problem -- DIDs enable you to look up cryptographic information
associated with identifier.
JoeAndrieu: If you say someting about subject -- if you say something about my car, it's not a statement about me. VCs contain things about subjects, we have privacy/security architecture about that -- DID Documents just don't have that.
markus_sabadello: I added a comment about this.
Wip: Not all of us here -- is anyone here opposed to changing language?
No objections
JoeAndrieu: We should check w/ Dave.
Wip: We could write a PR and see what he thinks.
w3c/did-resolution#38
JoeAndrieu: This is mostly a duplicate.
JoeAndrieu: Curious about how people feel about bengo's suggestion?
JoeAndrieu: he suggests that you may restrict access using some authentication/authorization process inbetween.
<denkeni> +1 to it. Some DID methods are consortium blockchain related.
w3c/did-resolution#38
w3c/did-resolution#244
Wip: We discussed this earlier today Markus -- dereferncing algorithm step 10 is problematic -- client returns error, but noted new language -- we think language around step 10 needs to change.
Wip: Steven is also recommending that we remove step 9.4
markus_sabadello: Im fine with changing that to Manu's proposal to simplify the step. I agree step 9.4 sounds strange -- has to do with RDF and semantic web applications where this doesn't necessarily mean retrieval -- sometimes in semantic web there are use cases where URI there is no URL meaning/processing of URI is determined by client.
markus_sabadello: I'd be fine with removing it if it sounds too strange, something related to URI philosophy and theoretical constructs, but also fine w/ removing it.
Wip: I think I'm hearing remove 9.4 and refactor 10 to use Manu's language.
Wip: Those are all the discuss issues.
Wip: We're going to move on to test suite now
DID Resolution Test Suite
w3c/did-resolution#239
Wip: There are duplicated satements, we might want to remove items.
Wip: Same requirement -- second normative statement we probably don't need it
manu: +1, don't need it.
JoeAndrieu: We only have one conformant representation.
Wip: That's a separate issue.
JoeAndrieu: We had a long discussion about this w/ VCs -- we say that things that can be transformed into VCs are VCs... you can't give me a media type and not be serialized in that format.
Section about representations: https://
JoeAndrieu: This is all legacy
JoeAndrieu: This could confuse the market -- we don't want to revisit that -- it would be better if we could update via wisdom learned from that conversation
manu_: I tried to modify the spec according to the charter
… I tried to do the minimal changes possible
JoeAndrieu: If you send me someething that is not a DID Document, it shouldn't work.
pchampin: This isn't aying media type should be the same.
JoeAndrieu: The media type defines the serialization, and we have one media type and one serialization.
JoeAndrieu: All this laguage creates confusion that we don't need to have.
Wip: This has been my sense, but relates to use of accept -- if we have one media type, and you do did resolution if there is an accept header, why do we have this?
Wip: markus_sabadello has said you might ask for CBOR, application/did-cbor -- not a DID Document, repreentation that can be tranforme dinto a DID Document.
markus_sabadello: I'm not sure, Joe -- we did remove abstract data model, there could be other representations... don't know what this means for accept option, still makes sense to have that.
JoeAndrieu: To speak to accept header, in DID Resolution, enabling feature extensibility, but we don't ave any use for it right now.
manu_: I don't think the language says you can shove anything that is not application/did in the resolution result
… I agree this is confusing to have production and consumption rules in DID 1.1 when we only have one media type
… there are many normative requirements in this section. I wanted to avoid making class 4 changes
Wip: We got off topic on this -- feels like this group doesn't have time to take that on -- do we want to raise an issue on didv1.1 and label it future. I'd be wary about getting this in.
Wip: Back to 239 -- are we ok w/ the suggested change -- no duplicate requirements. I'm going to make this change
JoeAndrieu: +1
markus_sabadello: The change would be to remove the second statement -- yes, that's fine. We can remove/change it to say resolvers might support multiple DID Methods.
JoeAndrieu: I think I understood your pushback -- that's not what this issue is about -- can we change conformant representation -- I think it's understood that a non-conformant representation is not what we're talking about.
w3c/did-resolution#223
Wip: The read operation can tells you what to do
markus_sabadello: This is for DID Methods that require certain resolution options -- that would be in context of specific DID Method, resolution only works if resolution option is passed to the method
<Zakim> JoeAndrieu, you wanted to say this is test requirement
JoeAndrieu: I don't know if we do this anywhere else, this is a requirement on the test suite -- we don't have any normative requirements on client of resolver, we could sepcify requirements on test suite.
Wip: The test suite is testing a universal resolver, you pass in a DID and some options and you get back resolution result -- I'm trying to test inputs/outputs.
JoeAndrieu: Dereferencing tests start w/ DID URL and they must do this.
Wip: The way you test it is by having verifiable input -- these resolution option are required -- this DID URL pass it over to universal resolvers API - in test suite -- it's ablack box, I can't go in there and check to see if options have been passed.
JoeAndrieu: We don't have a way of transforming input and getting signatue of the call. My own unit tests would teest this, I'd isolate the function away from the APi.
Wip: Yes, here is my API, ehre are some dids you can test it with -- that's what the test suite does. DID Methods are going to put requirements to pass on sidecar data -- ensure information is passed in... what could we change this to -- resolution options passed to read option, could be just execute read operation.
JoeAndrieu: This is a requirement of unviersal resolver, not any particular resolver.
JoeAndrieu: When I make a BTCR2 resolver, it has resolution options because its a single component. When we write something that isn't designed for universal resolver, you give DID and get back DID Document -- it already has parameters.
JoeAndrieu: I don't disagree w/ markus_sabadello framing.
JoeAndrieu: Maybe we should just remove it.
JoeAndrieu: We are not standardizing the architecture of the universal resolver.
manu: +1 to remove
markus_sabadello: I don't really see how this is specific to universal resolver -- this applies to any resolver
markus_sabadello: In my mind, the sentence here wrt. read operation is very generic, pasing it doen't mean sending it over the wires -- if it's hard to test then maybe remove, but it's not specific to universal resolver.
Wip: What Joe si getting at, if I care about DID method, I'm going to implement the resolver spec by combining both interfaces... but in practice, they might do resolver for single DID Method.
<Zakim> JoeAndrieu, you wanted to say did btcr2 doesn't have a read method
manu: this is impossible to test, let's remove it.
JoeAndrieu: BTRC2 doesn't have a read method, we have a resolve mechanism and a resolver implements it.
Wip: ok, consensus is we're going to remove this statement.
w3c/did-resolution#222
Wip: This is a duplicate normative requirement.
Wip: Let's remove the second statement.
manu: +1
JoeAndrieu: Aren't we using problem details instead of error properties -- errors could be different.
Wip: Error property is an property in did resolution metadata, that error property is a ProblemDetails object.
DID Resolution Test Suite
w3c-ccg/did-resolution-mocha-test-suite#17
Wip: How do I get tests that provide this sort of result?
JoeAndrieu: I don't know if we have requirements to have public keys -- we have verification methods, not public keys -- it's a use cases question, what would trigger these... some of these are intellectual exercise that identify real problems that might cause issues because of the spec.
Wip: markus_sabadello thoughts on this?
manu_: I think the error is invalid verification methon
… I am wondering if the way to test this is through DID key
… It could be that we just delete five of these return values
manu: We don't throw any of these PUBLIC_KEY errors in the spec, we should delete them.
manu: We don't throw INTErNAL_ERROR either
JoeAndrieu: We need to -- what happens when you have a bug?
manu: We need to say something about it in the algorithm -- it needs to be normative.
markus_sabadello: These errors could still be in extension registry -- we need to add sentence or two in algorithm that mentions these errors.
Wip: I'll create new issue to review all errors in error section, identify errors not in algorithm, either we remove it and put it in extensions or we add step in algorithm that throws that error
JoeAndrieu: Yes, +1, because we might have an error in the algorithm.
Wip: In BTCR2 - we had need in resolver to throw an error, we defined something to ensure -- invalid_did_document isn't thrown anywhere, but maybe DID method would throw a part of their algorithm.
Wip: We are expecting DID Methods to use these errors, would be nice for them to be already defined.
JoeAndrieu: The invalid did document error is return from dereferncing call -- everthing might look good from resolution process, but what it got back was not valid DID Document.
JoeAndrieu: Algorithm is check the spec and see where we say to return these things.
JoeAndrieu: For 404 not found, do we need to determine DID Document not found and resource not found?
pchampin: Let's not define error codes for specific DID Methods, but we do need generic placeholder for METHOD_SPECIFIC_ERROR.
markus_sabadello: Rgarding Joe's question -- don't think we need to differentiate between DID Document not found and resource not found, they can share same error code -- we could also split them.
JoeAndrieu: My concern is that dereferncing function call is going to respond the same way to both DID DOcument not bieng able to be found and Linked Resource not being found -- feels like we're losing information.
markus_sabadello: it wouldn't respond in the same way -- DID Resolution result is...
JoeAndrieu: I'm not calling resolver, calling dereferencer -- dereferencing response doen't get the same thing s aresolution?
markus_sabadello: dereferencing result or resolution result -- those are different.
JoeAndrieu: if URL dereferencing fails, do I get back entirety of response from rsolution action?
markus_sabadello: yes, you get the whole thing back.
JoeAndrieu: Ok
Wip: Yes, lets move on, that was useful.
w3c-ccg/did-resolution-mocha-test-suite#14
Wip: We're saying DID Resolution MUST implement the algorithm.
manu: This is duplicative, we should remove it -- we say the same thing in conformance section.
JoeAndrieu: +1 to remove because it's duplicative.
w3c-ccg/did-resolution-mocha-test-suite#15
Wip: Feels like normative requirement on an extension.
Wip: This is not a requirement on the DID Resolver.
manu: We should move this to the registry and put it in the registration requirements.
w3c-ccg/did-resolution-mocha-test-suite#16
Wip: This is untestable.
JoeAndrieu: Remove
manu: +1
markus_sabadello: In DID Core, we have a section about DID Methods and MUST statements there -- why would we remove this?
manu: We can't move this to DID pec because it's class 4 -- and even if we did, we'd have to define how to put proofs on DID DOcuments. We should wait until some DID Methods put proofs on their documents before generalizing the feature/reuiqmrent.
JoeAndrieu: I agree we can't move it to DID Core -- but wanted to comment on why untestable thing on DID Core -- testable by human, we can't automate it, but we do need to have these requirements. One of the places where we don't have automated/testable mechanisms for conformance statements we believe are important.
Wip: Are you ok if we remove, markus_sabadello ?
markus_sabadello: I agree, we can move on.