15:00:43 <RRSAgent> RRSAgent has joined #did
15:00:47 <RRSAgent> logging to https://www.w3.org/2025/04/17-did-irc
15:00:52 <ottomorac> rrsagent, draft minutes
15:00:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/17-did-minutes.html ottomorac
15:01:01 <ottomorac> rrsagent, make logs public
15:01:09 <ottomorac> Meeting: Decentralized Identifier Working Group
15:01:39 <ottomorac> Chair: ottomorac
15:01:52 <JoeAndrieu> JoeAndrieu has joined #did
15:02:07 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Apr/0006.html
15:03:08 <ivan> present+
15:03:21 <Wip> present+
15:03:21 <ottomorac> present+
15:03:21 <TallTed> TallTed has joined #did
15:03:21 <manu> present+
15:03:21 <markus_sabadello> present+
15:03:27 <dmitriz> dmitriz has joined #did
15:04:15 <dmitriz> present+
15:04:17 <dmitriz> scribe+
15:06:04 <KevinDean> KevinDean has joined #did
15:06:07 <KevinDean> present+
15:06:08 <TallTed> present+
15:06:23 <dmitriz> Wip: Agenda today is - horizontal review, abstract data model PR, then specific issues in DID Core (whether we want to allow method identifier to be HTTPS URLs)
15:06:33 <dmitriz> ... then problem details, did rubric, and traits discussion.
15:06:36 <dmitriz> ... over to you, Otto
15:06:51 <ottomorac> topic: Horizontal Review Update
15:06:56 <dmitriz> ottomorac: first topic, brief update on horizontal review
15:07:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/17-did-minutes.html TallTed
15:07:20 <dmitriz> ... we had a conversation to bring somebody in, I think Will at IIW had the conversation, but we decided not to
15:07:29 <pchampin> present+
15:07:33 <dmitriz> ... but anyways let's keep the topic in the agenda, to measure progress, to figure out the next steps
15:07:39 <Wip> q+
15:07:41 <manu> q+
15:07:44 <dmitriz> ... I'm assigned to work with Marcus on this, for the DID Resolution side
15:07:47 <ottomorac> ack wip
15:07:50 <TallTed> previous meeting: https://www.w3.org/2025/04/10-did-minutes.html
15:07:52 <TallTed> next meeting: https://www.w3.org/2025/04/24-did-minutes.html
15:07:58 <dmitriz> Wip: I'll help out on the DID Resolution side
15:08:08 <ottomorac> q?
15:08:20 <ottomorac> ack manu
15:08:24 <dmitriz> ... I've just been diving into familiarizing with issues. and started working on an Explainer for DID Resolution
15:08:41 <dmitriz> manu: update from my side - I took a look at the old DID Explainer doc we had. and it's 6 years old at this point
15:08:56 <Wip> did-resolution issue is here - https://github.com/w3c/did-resolution/issues/139
15:09:01 <dmitriz> ... much of it is still relevant. I took a shot at pointing AI to summarize our document, see if it results in a better Explainer
15:09:06 <dmitriz> ... so, that's what I'm looking at right now
15:09:09 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/17-did-minutes.html TallTed
15:09:15 <Wip> did-core is here https://github.com/w3c/did/issues/885
15:09:15 <dmitriz> ... I don't expect it to take too much time
15:09:23 <dmitriz> ... one suggestion to Otto and Will -- deal with the easiest groups first.
15:09:45 <dmitriz> ... the Accessibility Review is probably the easiest one, cause we don't really have anything to do with accessibility, so a lot of it will be 'doesn[t apply'
15:10:05 <dmitriz> ... Internationalization one will be next best. we do have some considerations, but should be fairly easy
15:10:28 <dmitriz> ... and then Security and Privacy. and do TAG last, since they require the most amount of new content
15:10:32 <JennieM> JennieM has joined #did
15:10:35 <JennieM> present+
15:10:46 <ottomorac> q?
15:10:46 <dmitriz> ... it all doesn't have to be done at the same time, you can stagger it, they're not tied together
15:11:03 <dmitriz> ottomorac: thanks Manu. I'll get started on this with Marcus
15:11:19 <dmitriz> ... next one is - the first PR we want to review
15:11:21 <ottomorac> Topic: Simplify abstract data model and specify one concrete representation
15:11:26 <ottomorac> https://github.com/w3c/did/pull/887
15:11:48 <manu> q+
15:12:30 <dmitriz> ... this one is -- so, we said we'd try to eliminate the abstract data model, and follow the CID spec (establishing the algorithm)
15:12:40 <ottomorac> ack manu
15:13:02 <dmitriz> manu: good summary, I think I said that I'd leave this open til this week, and if we didn't get more feedback, we'll merge it in
15:13:11 <JennieM> JennieM has joined #did
15:13:12 <dmitriz> ... so, I'll merge it by the end of the weekend
15:13:21 <dmitriz> ... I think it's fine as is, I don't think it'll blow anything up
15:13:39 <dmitriz> ... just to be clear, there are not supposed to be any normative changes (rather, no change in functionality at all in DID implementations)
15:13:47 <ottomorac> q?
15:14:00 <JoeAndrieu> q+
15:14:07 <dmitriz> manu: Marcus, I tried to re-do the image (the diagram)
15:14:15 <dmitriz> ... and tried using Inkscape, and no luck rendering it
15:14:18 <dmitriz> ... which app did you use?
15:14:49 <dmitriz> markus_sabadello: I used LibreOffice Draw I think?
15:15:10 <dmitriz> ... I have the source files for all of these, I can send you source files. Or I could update them
15:15:22 <dmitriz> manu: source files would be good, we should check it into version control
15:15:23 <ottomorac> q?
15:15:39 <dmitriz> markus_sabadello: yeah, I ran into some problems as well
15:15:42 <dmitriz> manu: yeah, just raise a PR to check in the source files
15:16:15 <ottomorac> ack JoeAndrieu
15:16:41 <dmitriz> JoeAndrieu: there's a line in there that implies CBOR and YAML that are valid representations, and I think that's not quite accurate anymore
15:16:44 <dmitriz> manu: ok, sounds good
15:17:32 <dmitriz> ... that sounds fine. I was trying to imply -- if somebody had say a YAML representation, as long as they could convert to a concrete representation (JSON doc), and then send it to you, it'd be fine
15:17:58 <dmitriz> JoeAndrieu: if you wanted to include something like "Internal representations could use other formats", I could support that. As long as we're clear that the thing going over the wire needs to be JSON
15:18:07 <dmitriz> manu: I see ok
15:18:28 <pchampin> q+
15:18:49 <dmitriz> manu: I'm trying to head off comments on "CBOR is illegal" etc.
15:19:00 <ottomorac> q?
15:19:01 <dmitriz> JoeAndrieu: well that's the point though - it's not a legal over-the-wire representation
15:19:16 <dmitriz> ... if you want to call out internal, that's fine
15:19:17 <manu> q+
15:19:20 <Wip> q+
15:19:28 <ottomorac> ack pchampin
15:19:39 <dmitriz> pchampin: I thought I'd put a comment on the PR, but looks like not
15:19:50 <dmitriz> ... I want to recall Ivan's concern about 'generalized JSON-LD processing'
15:19:56 <dmitriz> ... I looked at the CID document
15:20:11 <dmitriz> ... and the source document actually distinguishes normal JSON processing from generalized JSON-LD processing
15:20:31 <dmitriz> ... the 'generalized' part seems very odd to me
15:20:32 <ottomorac> q?
15:20:36 <dmitriz> ... maybe I should try to propose a fix
15:20:40 <ivan> q+
15:20:41 <ottomorac> ack manu
15:20:49 <dmitriz> manu: yeah, this is where this PR is difficult
15:21:05 <dmitriz> ... since we can't make Class 4 changes, I can't quite say what we want
15:21:17 <dmitriz> ... we can't get rid of representation changes, since there are normative statements that involve them
15:21:21 <dmitriz> ... so we can't remove those
15:21:41 <dmitriz> ... so I had to keep representations language around. we're trying to get it down to just _one_ JSON representation
15:21:51 <dmitriz> ... and the generalized processing thing is just trying to say -- don't break JSON-LD processors
15:22:06 <dmitriz> ... you can go field by field JSON processing. but your output shouldn't break JSON-LD
15:22:11 <dmitriz> ... that's the consensus we were able to get
15:22:26 <dmitriz> ... for people who just want to look at the JSON, look at the type, do some processing
15:22:46 <dmitriz> ... so it's fine if you do that, but whatever the outcome is, semantically, it still has to match up with how JSON-LD would've processed it, otherwise, there's a bug
15:22:54 <Wip> q-
15:23:02 <dmitriz> ... and that's the language that we reached consensus on with Google and others, who are generally against polyglot processing
15:23:04 <ottomorac> q?
15:23:10 <dmitriz> ... so that's why -- we're trying to not change anything normative.
15:23:21 <dmitriz> ... with a JSON mechanism, but is 100% compat with JSON-LD
15:23:39 <dmitriz> ... which would result in no Class 4 changes
15:23:44 <ottomorac> ack ivan
15:24:14 <dmitriz> ivan: to me, the term 'generalized JSON-LD processing' at that point doesn't bring anything
15:24:23 <dmitriz> ... that I wouldn't have just by saying 'JSON-LD processing'
15:24:36 <dmitriz> ... the latter has a clear meaning, via the JSON-LD standard
15:24:50 <manu> q+ to note that Dave has strong feelings about this. :)
15:24:52 <dmitriz> ... the current language uses the term 'generalized JSON-LD proc' _in contrast_ with the type-specific thing
15:25:03 <dmitriz> ... I don't quite know how to put it clearly, but..
15:25:11 <dmitriz> ... somehow, I don't know what to do with this term
15:25:16 <dmitriz> ... I'd simply remove the 'generalized' term
15:25:20 <pchampin> in fact, the text says twice "generalIZED json-ld processing" and twice "general json-ld processing"; I prefer the second wording
15:25:21 <ottomorac> ack manu
15:25:21 <Zakim> manu, you wanted to note that Dave has strong feelings about this. :)
15:25:39 <dmitriz> manu: Dave Longley had some pretty strong feelings about this, I'd hesitate to change it
15:25:50 <dmitriz> ... and I do think Dave has got a point. there are the algorithms in the JSON-LD spec and API spec.
15:26:14 <dmitriz> ... and that's what we're calling 'generalized JSON-LD processing'. meaning, you can take a generalized JSON-LD processor, you process it, and get a result
15:26:25 <dmitriz> ... because you can ALSO do non-generalized JSON-LD processing, you can do type-specific
15:26:30 <pchampin> q+
15:26:40 <dmitriz> ... so, it's ok to not use a JSON-LD library to process the document
15:26:58 <dmitriz> ... so, one class is - 'generalized JSON-LD' is you're using a 100% standards-compliant JSON-LD library to do processing
15:26:59 <pchampin> q-
15:27:01 <bigbluehat> bigbluehat has joined #did
15:27:16 <dmitriz> ... and the OTHER approach is you don't have a JSON-LD processor, you can do whatever manual processing,
15:27:24 <dmitriz> but as long as the outcome is semantically the same, that's important
15:27:34 <bigbluehat> present+
15:27:39 <dmitriz> ivan: ok, let's move it to the PR discussion
15:27:39 <dmitriz> ... I'm not entirely convinced
15:27:53 <dmitriz> manu: if there's a better language we can use.. hopefully this is a future JSON-LD WG discussion
15:28:11 <dmitriz> ... there are people that deeply hate JSON-LD libraries, and they're insisting that it's the only way to get proper output,
15:28:22 <dmitriz> ... and there's another group saying -- no, you can just treat it as JSON, etc
15:28:29 <dmitriz> ... so, this needs better language.
15:28:34 <ottomorac> q?
15:28:44 <dmitriz> ... and the best language so far was from the VC WG, which Google said they'd be ok with, etc
15:29:06 <dmitriz> ottomorac: thanks, we'll come back to this.
15:29:16 <ottomorac> Topic: DID Resolution:  Consider use of "Problem Details" in case of errors
15:29:20 <ottomorac> https://github.com/w3c/did-resolution/issues/87
15:29:20 <Wip> q+
15:29:39 <dmitriz> ottomorac: on this PR, we said initially that it's a good idea to settle on some problem details,
15:29:39 <dmitriz> ... there was some agreement to put it in the spec
15:29:44 <dmitriz> ... not sure if Manu had a chance
15:29:53 <dmitriz> manu: no, I've not had any time, and forgot completely about it. it's on the queue
15:30:03 <dmitriz> ottomorac: ok, if people agree with the issue, we can just move on
15:30:10 <ottomorac> ack Wip
15:30:21 <dmitriz> Wip: I thought I'd take this on, Manu.
15:30:31 <dmitriz> ... the issue is adding Problem Details to define errors
15:30:34 <manu> q+
15:30:41 <dmitriz> ... the DID spec just has a generic 'error' property and string name
15:31:06 <dmitriz> ... as I looked into the issue, -- should we be supporting BOTH the 'error' property from the 1.0 spec, AND the details approach from the CID spec
15:31:15 <dmitriz> ... for backwards compat
15:31:22 <manu> q+
15:31:26 <ottomorac> ack manu
15:31:39 <dmitriz> manu: I might be confused.. the Problem Details thing is on the DID Resolution spec
15:31:43 <dmitriz> ... and we're not bound to any class of changes there, since it's new
15:31:54 <dmitriz> ... we're also defining a vocab for resolution, right Markus?
15:31:58 <Wip> thats true actually
15:32:09 <dmitriz> ... I know that, Ivan, somewhere on the internet, there's an issue about needing a vocab for DIDs
15:32:17 <dmitriz> ... anyways, the Problem Details enums go into one of those two
15:32:22 <Wip> q+
15:32:24 <dmitriz> ... but neither one of them are in theory normative
15:32:27 <markus_sabadello> q+
15:32:34 <Wip> q-
15:32:40 <ivan> q+
15:32:42 <dmitriz> ... so we just need to figure out which vocab doc (DID or DID Resolution)
15:32:44 <ottomorac> q?
15:33:15 <dmitriz> ... the Security vocab might have some very generic problem types we might want to reuse?... looking..
15:33:18 <ivan> I think Manu refers to this: https://github.com/w3c/did/issues/884
15:33:22 <dmitriz> ... stuff like 'invalid controller' etc
15:33:46 <dmitriz> ... so maybe we'll reuse some terms from Security vocab. and some things are very DID-Resolution-specific, that we'll define in its vocab
15:34:08 <dmitriz> ... does that give you a clear path forward?
15:34:11 <ottomorac> ack markus_sabadello
15:34:14 <dmitriz> Wip: kind of, I want to hear what Markus has to say
15:34:29 <dmitriz> markus_sabadello: in DID Resolution, we have a JSON-LD context, we don't have a vocab
15:34:45 <Wip> q+
15:34:51 <dmitriz> ... I agree that the Problem Details should be in the DID Resolution vocab, we'll add it there. and agree we'll look through Security vocab and see what we can reuse
15:35:04 <dmitriz> ... only issue is -- we have already defined a few error codes in DID Core 1.0
15:35:10 <dmitriz> ... so we're somewhat bound by that
15:35:24 <dmitriz> ...  like 'invalid did' and 'not found'
15:35:39 <dmitriz> ... and they're capitalized in a different way than in the Problem Details and CID spec
15:35:46 <ottomorac> ack ivan
15:35:47 <dmitriz> ... so that's the only remaining question - how do we align/reconcile
15:35:52 <Wip> +1 that is where I am confused too
15:35:54 <dmitriz> ivan: manu, you opened the floodgates
15:36:07 <dmitriz> ... there are several things here. yes, first of all, we need a proper vocab for DID Core,
15:36:20 <dmitriz> ... and I raised an issue several weeks ago on this
15:36:28 <dmitriz> ... we have the tools inherited from the VC WG to do that, so it just must be done
15:36:51 <dmitriz> ... as a side question -- in VC, what we agreed upon is that the vocab definition itself, which is an HTML file, a TTL file, and a JSON-LD file for vocabs, are non-normative
15:36:55 <ottomorac> q?
15:36:57 <dmitriz> ... the normative definition must be in the spec
15:37:08 <dmitriz> ... DID Resolution -- there are two things to be answered
15:37:27 <dmitriz> ... first, I think it was an issue discussed last week, do we really to use JSON-LD in the DID Resolution spec, or not?
15:37:39 <dmitriz> ... because if we do, then of course we need a vocabulary, just like DID
15:37:51 <dmitriz> ... if we don't need to use JSON-LD in the Resolution spec, then it's moot
15:37:53 <manu> q+ to note we don't need to use JSON-LD for DID Resolution responses.
15:38:26 <dmitriz> ... the second question is -- provided we want to do JSON-LD in the Resolution Spec, it becomes an editorial question whether we do one big vocab that includes both DID and DID Resolution (so it's easier to maintain), or whether we want to separate the two
15:38:56 <dmitriz> ... noting that the DID vocab per se (the one I made experimentally) is very small, since DID Core defines only ONE item, it takes the other terms from elsewhere
15:39:23 <dmitriz> ... re JSON-LD and DID Resolution, my personal belief is that it's unnecessary / uninteresting, we don't need it
15:39:40 <ottomorac> ack Wip
15:39:48 <Wip> https://www.w3.org/TR/did-1.0/#did-resolution-metadata
15:39:55 <dmitriz> Wip: great, this is less complicated than I thought
15:39:59 <Wip> https://w3c.github.io/did-resolution/#errors
15:40:02 <KevinDean> KevinDean has joined #did
15:40:04 <dmitriz> ... we do want to take the 3 error codes from DID 1.0
15:40:09 <dmitriz> ... I thought there were many more
15:40:25 <dmitriz> ... so, one approach is -- we change all the error codes to be in the Problem Details approach, like the CID spec
15:40:44 <dmitriz> ... another option is, we continue to support the 'error' property in the result, and ALSO add a 'problem details' property, which is what Markus proposed
15:40:50 <dmitriz> ... so, looking for directions from the group
15:41:04 <ottomorac> ack manu
15:41:04 <Zakim> manu, you wanted to note we don't need to use JSON-LD for DID Resolution responses.
15:41:06 <dmitriz> ... so, like for Invalid DID, we keep the error string, and ALSO define a problem details object for it
15:41:18 <dmitriz> manu: going back to what Ivan said, I agree with everything he said
15:41:22 <smccown> smccown has joined #did
15:41:29 <markus_sabadello> q+
15:41:42 <dmitriz> ... we don't need a vocab for DID Resolution, and we don't need to use JSON-LD at all in the API or responses.
15:41:54 <dmitriz> ... I don't remember if we have a use case for DID Resolution vocab?
15:42:05 <dmitriz> ... in any case, I think we only need to define a DID core vocab. and it'll have only one entry
15:42:11 <dmitriz> ... and that's where we'll put the problem detail definitions
15:42:17 <dmitriz> ... and because it's non-normative, we can just do that, and be ok
15:42:26 <ottomorac> ack markus_sabadello
15:42:37 <dmitriz> markus_sabadello: I added some thoughts on the JSON and JSON-LD question, in the issue that ivan created
15:43:00 <dmitriz> ... I would prefer to continue to use JSON-LD for the resolution result
15:43:17 <dmitriz> ... i don't want to repeat the comments there, I'll paste the link to the issue
15:43:26 <dmitriz> ottomorac: moving on to the other topic
15:43:27 <ottomorac> Topic: DID Rubric & Traits discussion
15:43:35 <ottomorac> https://github.com/w3c/did-extensions/issues/619
15:44:09 <markus_sabadello> See discussion here about JSON and JSON-LD for DID Resolution Result: https://github.com/w3c/did-resolution/issues/137
15:44:44 <dmitriz> ottomorac: I'd like to introduce Jan Christoph Ebersbach
15:44:55 <dmitriz> JCE: thanks, we continued to work on the DID Traits effort at DIF
15:45:12 <dmitriz> ... the idea was to provide a list of relevant features or trait that DIDs use, and record them in a machine-readable format
15:45:22 <ottomorac> https://identity.foundation/did-traits/
15:45:39 <dmitriz> ... we have different traits like Self-Certifying Identifiers, etc
15:45:48 <dmitriz> ... we thought about how are we going to use this list of traits. and one way we found useful is to create an overview
15:45:53 <dmitriz> ... to compare different DID Methods
15:46:18 <dmitriz> ... so the did-traits link has a comparison table that gives an idea of how they can be used
15:46:35 <dmitriz> ... and I raised an issue in the DID Extensions repo to discuss possible integration of Traits into the extension registry
15:46:46 <dmitriz> ... so that method authors can record traits in their registration entry
15:46:55 <ottomorac> q?
15:46:58 <manu> q+
15:47:05 <ottomorac> ack manu
15:47:16 <dmitriz> manu: thank you JCE and ottomorac for this wonderful work
15:47:40 <dmitriz> ... one way we can do the integration is - when DIDs are registered in the Extensions list, we could add a field to the registration, that's quite literally reuses the JSON Schema you provided
15:47:54 <JoeAndrieu> q+ to suggest we should build on the rubric
15:47:57 <dmitriz> ... so that when people go in and register, they can also, through a property called 'traits', list all the traits that apply
15:48:06 <dmitriz> ... which would allow them to set booleans to true, or whatever it is
15:48:13 <dmitriz> ... that might be the easiest integration path
15:48:27 <dmitriz> ... there are other secondary things like - do we want people to be able to select traits, and filter the extensions list?
15:48:35 <dmitriz> ... but obv we need data to do that
15:48:55 <dmitriz> ... the question I have for you JCE and Otto is -- how ready to go do you feel Traits are?
15:49:11 <dmitriz> ... I'm sure we'll add them over time, etc. do we point elsewhere for the Traits schema? does the WG have to review all the traits and agree?
15:49:22 <dmitriz> ... those are the open question I have. but the integration feels straightforward and mechanical to me
15:49:50 <dmitriz> JCE: the main thing is - we received approval from the DIF WG for the version 0.8
15:49:55 <dmitriz> ... we're currently pursuing v1.0
15:49:58 <ottomorac> q?
15:50:04 <dmitriz> ... we did receive some feedback, and there will be additional changes to the list
15:50:06 <Wip> q+
15:50:26 <dmitriz> ... in general, the Traits are represented as booleans, we tried to stick with Traits that are very technical (and therefore CAN be represented with booleans, and still convey value and meaning)
15:50:47 <dmitriz> ... I'd say we've covered a lot of ground with Traits already. and of course want additional feedback
15:51:07 <dmitriz> ... in the future, the list will be extended, like you said Manu. a good way would be to go through DIF for extensions
15:51:18 <dmitriz> ... I'm not bound to keeping the Traits spec at DIF
15:51:23 <manu> q+
15:51:26 <dmitriz> ... maybe it'd be easier to integrate with W3C, to have under one roof
15:51:36 <ottomorac> ack JoeAndrieu
15:51:36 <Zakim> JoeAndrieu, you wanted to suggest we should build on the rubric
15:51:39 <dmitriz> ... but that's more a question for you all
15:51:57 <dmitriz> JoeAndrieu: I'm a bit confused by the tone of conversation -- we passed a resolution to explore how to integrate Traits with the Rubric
15:52:05 <dmitriz> ... we had a good conversation. i think the DID Traits do fit
15:52:14 <dmitriz> ... for each trait that exists, we can create a Criteria in the Rubric
15:52:30 <dmitriz> ... I would be opposed to putting DID Traits in to the Extensions registry, and ignoring the work we've done on the Rubric
15:52:39 <ottomorac> ack Wip
15:52:39 <dmitriz> ... I'd like to see how we can integrate the two, before adding to the Extension
15:52:47 <markus_sabadello> q+
15:52:55 <dmitriz> Wip: with chair hat off, I agree with Joe
15:53:16 <dmitriz> ... for example, one of the trait is Multi-Signature Verification method. and if I understand, ANY DIDs can support multi signature
15:53:21 <dmitriz> ... at least that's how I understand it
15:53:38 <ottomorac> q?
15:53:39 <dmitriz> ... and that highlights a challenge with the DID Traits approach
15:53:39 <dmitriz> ... that there's just boolean flags to check,
15:53:43 <ottomorac> ack Manu
15:53:52 <dmitriz> manu: couple of thoughts
15:54:06 <dmitriz> ... seems like there's a desire to at least move the Traits work into this WG in some way, and integrate it in some way
15:54:15 <dmitriz> ... whether through the Rubric, or as items in the DID Extensions registry
15:54:26 <dmitriz> ... so we just need to figure out how it happens
15:54:40 <dmitriz> ... I agree with Will's point -- all these different verification methods, every DID method should support all of thsoe,
15:54:43 <ottomorac> I will note that I agree that this needs to evolve into W3C as well, not sure what form though
15:54:48 <dmitriz> ... so those boxes will always be checked
15:55:01 <dmitriz> ... I don't view this as throwing out whatever work was done with the Rubric
15:55:19 <dmitriz> ... I'm most interested in a way for people to filter DID Methods based on features / criteria, at least on a high level
15:55:34 <ottomorac> q?
15:55:39 <dmitriz> ... there's some criteria we just can't make into a checkbox. but some, we can!
15:55:46 <dmitriz> ... so, any kind of downselecting / filtering mechanism would be better than just a giant list of 200+ did methods
15:55:59 <dmitriz> ... so, question is - what's the next step for the group?
15:56:10 <dmitriz> ... does DIF have any interest in handing some of this over to W3C? IP-wise etc
15:56:26 <dmitriz> ... I don't think there'd be much IP concerns -- it was incubated at DIF, can be handed to the WG, etc
15:56:28 <ottomorac> q?
15:56:31 <ottomorac> q+
15:56:42 <dmitriz> ... again, thing I care most about is the end result -- will people have a better way of navigating the DID methods
15:56:50 <dmitriz> ... otherwise, it'll be overwhelming / not very useful
15:57:00 <ottomorac> ack markus_sabadello
15:57:14 <dmitriz> markus_sabadello: I think both DID Traits and the Rubric are very useful tools for this kind of filtering
15:57:24 <dmitriz> ... therefore I'd be very excited to integrate it with the Extensions registry
15:57:39 <dmitriz> ... I admit I don't remember exactly the resolution we passed previously about integrating Traits with Rubric
15:57:49 <ottomorac> q?
15:57:53 <dmitriz> ... I think one of the aspects was - traits has boolean flags, whereas Rubric was more extensive
15:58:10 <dmitriz> ... I wonder if this integration is -- I understand what Joe is saying about the order of procedure
15:58:31 <dmitriz> ... but I wonder if there's any downside to integrating Traits with Extensions in parallel to integrating Rubrics with traits and extensions
15:58:39 <dmitriz> ... regarding contributions from DIF - maybe JCE can clarify
15:58:50 <Wip> These are our resolutions - https://www.w3.org/2024/list-resolutions/?g=did. Most relevant is https://www.w3.org/2025/02/20-did-minutes.html#0130
15:59:08 <ottomorac> ack ottomorac
15:59:21 <dmitriz> JCE: just to acknowledge the point, Will just pasted the specific link to the resolution
15:59:39 <dmitriz> ... this was discussed, I remember,
15:59:48 <JoeAndrieu> q+ to speak to the challenge of embedding current format (as Traits), which is incompatible with the Rubric. Whereas the new JSON rubric model would allow the a rubric evaluation to encompass all of what would be in did traits
15:59:50 <dmitriz> s/JCE: just to acknowledge/ottomorac: just to acknowledge/
16:00:08 <dmitriz> JCE: so, two things - with regards to data collection, the right place is the DID Extensions Registry
16:00:37 <dmitriz> ... and where the spec is maintained -- it's not an issue to move it away from DIF, if it's better to move it to W3C, no prob, we'll talk internally at DIF and discuss it, but feels like no obstacles
16:00:47 <ottomorac> q?
16:00:58 <ottomorac> zakim, close the queue
16:00:58 <Zakim> ok, ottomorac, the speaker queue is closed
16:01:12 <JoeAndrieu> q-
16:01:13 <dmitriz> ... one additional point regarding different traits -- we do have a definition of each trait. so if you're not 100% sure what a trait means, there's a more detailed description. if you have questions, please raise issues on the tracker
16:01:27 <dmitriz> ... next step wise, to me it feels like we should wait for the 1.0 approval of DID Traits by DIF
16:01:50 <dmitriz> ... and then we can pursue the integration officially with Extensions registry etc. and in the meantime, we can prepare a PR so that we can start experimenting with the integration
16:02:00 <dmitriz> ... maybe also work on some display / filtering code
16:02:00 <JoeAndrieu> I would oppose integration that didn't enable Rubric evaluations in the same manner
16:02:24 <dmitriz> ottomorac: thanks all, we'll continue discussion in the next call
16:04:35 <ottomorac> rrsagent, make minutes
16:04:36 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/17-did-minutes.html ottomorac
16:06:20 <ottomorac> m2gbot, link issues with transcript
16:06:21 <m2gbot> comment created: https://github.com/w3c/did/pull/887#issuecomment-2813444879
16:06:22 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/87#issuecomment-2813444912
16:06:23 <m2gbot> comment created: https://github.com/w3c/did-extensions/issues/619#issuecomment-2813444955
16:07:06 <ottomorac> zakim, end the meeting
16:07:06 <Zakim> As of this point the attendees have been ivan, Wip, ottomorac, manu, markus_sabadello, dmitriz, KevinDean, TallTed, pchampin, JennieM, bigbluehat
16:07:08 <Zakim> RRSAgent, please draft minutes
16:07:09 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/17-did-minutes.html Zakim
16:07:15 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:07:16 <Zakim> Zakim has left #did
16:18:40 <ottomorac> RRSAgent, please excuse us
16:18:40 <RRSAgent> I see no action items