Meeting minutes
<ottomorac> ok cool
<ottomorac> I will attend
<KevinDean> https://
Wip: ottomorac is new, do you want to introduce yourself?
ottomorac: Thank you all for inviting me, I am looking to engage more in the standards space. I'm definitely aligned with the values people in this group have expressed.
ottomorac: Looking forward to learning and collaborating and moving specs forward.
Wip: First announcement about APAC call, then talk about DID Core and DID Resolutoin
DIDWG APAC Announcement
Wip: This is because currently I'm the only chair and it's 1am for me: I talked to Denken who is active, and he is open to moving to an EU and APAC friendly timeslot.
Wip This may be a nice way to explore EU and APAC collaboration
Wip: Who could attend such a call?
Wip: Anyone from EU other than markus_sabadello who could attend that?
Wip: Currently the call is APAC and US friendly, 1am in UK.
Wip: We're looking at temporarily moving it.
ottomorac: I'm on US Eastern time, I could try to attend
<JoeAndrieu7> +1 for trying it
Wip: It wouldn't be a bad idea, since markus_sabadello is leading DID Resolution spec
Wip: Will talk to you ottomorac offline
Wip: I think APAC group has 4-5 regular participants
Wip: PA talk about application/did
application/did contentType
pchampin: I contacted editors of DID Core about registration of media type
pchampin: Basically our W3C guide says the first contact be sent to the IETF media type mailing list 2-3 months before Candidation Recommendation
pchampin: Based on discussion, may be better to do it sooner rather than later
pchampin: So my intention is to send first request for feedback to IETF basically now, based on media type description we currently have in DID Core.
pchampin: Does anyone think this is too early and we expect any radical change?
manu: I think in some of that email exchange.. We try to avoid similar issues as in application/vc.
manu: We just want to say we intend to register this. There is a provisional registry, but basically nobody uses that.
manu: But we can utilize this process right now to clearly signal what we intend to register so we don't end up in a similar situation as with application/vc.
manu: want to avoid previous issues with application / vc
manu: So let's do this now, so we have more time later.
manu: Another path we could take is that DID documents have existed for years, and we're just trying to register a media type for it. We can say that we're now getting around to registering it.
manu: The text is in the 1.1 spec, but we could register the media type for the existing global standard.
manu: I would prefer to try to just register it right now for the existing 1.0.
manu: we should try to register it right away. for 1.0
pchampin: I looked at the provisional registration and also found it's not used at all.
pchampin: If we contact the mailing list, we not provide the whole information and request feedback.
pchampin: I'm also open to using the provisional registry.
Wip: Sounds like a good step forward. Anyone opposed to trying to register for 1.0.?
<JoeAndrieu> +1 to register
<manu> +1 to register
Wip: Who will take that task to reach out to the chairs?
manu: I can do it. I mean it's typically staff contact who does the registration.
manu: It's a little weird maybe, since we register a media type for a previously published specification.
manu: You have to go to their website and fill out a registration template. We should just try. We have all the information.
Wip: Is this okay with you pchampin?
pchampin: Yes
<Zakim> JoeAndrieu, you wanted to discuss additional agenda item: Authentic Web mini-workshop on March 12 10am ET / 14:00 UTC
DID Core Issue Processing
JoeAndrieu: Here is a different agenda item, a mini-workshop in W3C. It overlaps with DID Special Topic Call, so let's not have a Special Topic Call that week.
manu: No open PRs in DID Core. For Class 3 issues, we just need to create PRs.
DID Resolution Issue & PR Processing
<PDL-ASU> presesnt +
<Wip> https://
marcus: yes, there a number of open PRs
markus_sabadello: A number of pull requests now, so we'll take a look at them.
… One of them is about moving the resolve presentation functions.
… With this pull request, we would have two functions in DID resolution, resolve and dereference.
markus_sabadello: Some of the pull requests are about enhancements and new features that we've discussed on other calls.
markus_sabadello: I've created a meta issue that summaries the discussion about these enhancements.
… The conclusion was that four of them we want to move to extensions, three we want in DID resolution itself, so pull requests have been created for those.
… Some of them need some work.
… I haven't prepared anything for the call for now.
<JoeAndrieu> +1
w3c/did-resolution#119
wip: This one adds version ID and version time to DID resolution options.
… It has some approvals.
… One of the questions I had, now that there's the same definition elsewhere in the spec, is it duplication or is there a different way we can write it?
… I basically copied the version ID and version time from the other part of the document.
markus_sabadello: We should just have the definition in one place.
… In general there are a number of places where they may be a DID parameter or a resolution option.
… If we want version ID or version time, it can be either a DID parameter or a resolution option.
… DID resolution options can be passed as parameters. It's expected that they can be part of the DID URL.
… In HTTP you can have query parameters or HTTP headers. One is part of the identifier, one is not. Version ID and version time can make sense both ways.
… We should find some way to improve the text so that they're defined in only one place.
Wip: I'll work on the PR.
w3c/did-resolution#122
Wip: I raised this to show a dereferencing option. We've had discussion about this before. Manu, you've said we should use what's already defined in the DID spec.
… Markus, I think you're right, it shouldn't go at the start, so that the dereferencing happens first. That means targeting a specific stack.
<Wip> https://
manu: There are a couple ways to do this. One way is to copy and paste the entire retrieval spec. The other is to define a section around retrieve verification method and defer most everything to the DID spec except anywhere that it says "URL" say that it must be dereferenced.
… +1 for defining this later on.
… I don't know if any of this is helping. What specific feedback are you looking for? +1 to having this defined.
… We should point to the DID retrieval as much as possible, refining the steps where necessary.
… Maybe the DID spec, but possibly the resolution spec, point to the algorithm and clarify steps as required.
Wip: My initial thought was I want to find all the verification methods in this DID that can be used for authentication.
… I've got a document with a proof on it and I make one call to the resolver and get one verification method if it's authorized for that specific proof.
manu: I think that's a valid use case. I wonder if we need something in the resolution spec to do that. You go to the document, and you go to the resolution for the proof. We could specify this and be very explicit, or we could leave it to implementers to write software libraries.
<Zakim> JoeAndrieu, you wanted to say as dereferencing it's good
manu: The problem with being specific about is that we need to write test suites for it.
manu: it would just be more work as conformance suites would be required
JoeAndrieu: We need to do something here. Right now, if you DID URL that ends in #key1, you're not going to get back the verification relationship. You're going to get back the JSON.
… I think that's the use case. I have a fragment identifier, but what I need is its parent attribute.
marcus: it would be useful to have this option...
markus_sabadello: I think it is useful to have this option, to instruct the resolver to return only the verification method if it matches or is authorized for the relationship.
… It may be a bit complicated if it overlaps with our dereferencing already. You have to check the input URL, the conformity of the document, there are a lot of rules that are generic dereferencing rules that are not specific to any method.
… What I would like to do is use this subset to retrieve the algorithm.
… There are other topics that need to be aligned.
Wip: I'll have another look at this.
… Joe, how much time do you need for DID rubric?
DID Rubric
https://
Wip: Over to you JoeAndrieu to summarize
JoeAndrieu: We had gone through what have we learned, what are we trying to do
JoeAndrieu: We passed 2 bullet points as resolutions. Ryan Grant and I will work on this.
JoeAndrieu: Let's now go over the remaining three for considerations
<Wip> ?
Wip: Thoughts about the proposal by JoeAndrieu about the JSON-driven rendering (third bullet point in the list)
JoeAndrieu: There is a Rubric HTML page, we want that to eventually be driven from a set of JSON files
Wip: Similar to methods.json in the methods list
Wip: Any suggestions to change it?
<JoeAndrieu> PROPOSAL: Transform the rubric html page into a JSON-driven rendering
<swcurran> +1
<manu> +1
<Wip> +
<JennieM> +1
<JoeAndrieu> +1
<Wip> +1
<markus_sabadello> +1
<danpape> +1
RESOLUTION: Transform the rubric html page into a JSON-driven rendering
ottomorac: great to see did-traits in there
JoeAndrieu: Next one is related to work with SVIP cohort.
JoeAndrieu: Some questions make sense for blockchain-based but not web-based methods.
JoeAndrieu: One mechanism is about integrity.
JoeAndrieu: We came up with a few questions that were not in the set.
JoeAndrieu: We want to move some of them over.
JoeAndrieu: Seems to be good work to bring into DID Rubric.
Wip: What would be the process for transferring this? Individual PRs?
JoeAndrieu: We want to go into JSON. https://
JoeAndrieu: It would be easiest for us to adjust the schema for evaluations
JoeAndrieu: I think it would be done all at once.
<JoeAndrieu> PROPOSAL: Import criteria from https://
<manu> +1
<JoeAndrieu> +1
<Wip> +1
<JennieM> +1
<denkeni> +1
<markus_sabadello> +1
<danpape> +1
<TallTed> +1
<pchampin> +1
RESOLUTION: Import criteria from https://
ottomorac: The thinking here is that we have a move live version of evaluations, with ongoing updates, as opposed to just a snapshot at a specific time.
JoeAndrieu: There are two things here. I'm thinking about DID Rubric maybe differently than you
JoeAndrieu: Rubric is a set of questions that anyone can work through
JoeAndrieu: It's not intended to be a place where we curate evaluations of DID methods
JoeAndrieu: Without examples, it's hard to understand criteria.
JoeAndrieu: But for the same DID method there could be different evaluations depending on a use cases's needs. Different people (e.g. consultants) could come up with different evaluations.
JoeAndrieu: We have struggled with stagnation, hoping that moving to JSON will change this.
JoeAndrieu: Next consideration is about DID Traits.
Wip: The purpose is not to hold authoritative evaluations.
Wip: This Rubric is not going to hold things like that
JoeAndrieu: That's right
JoeAndrieu: DID Traits is good work, feels complementary, a good fit.
JoeAndrieu: But I think the boolean framework of DID Traits is a bit different
JoeAndrieu: I'd like to get the endorsement of this group
<ottomorac> +1 makes sense
<JoeAndrieu> +1 for coordinating with DID Traits folks
manu: I just want to make sure there is agreement by DID Traits people, and what merging looks like.
manu: What's the plan exactly, will DID Traits continue to exist independently?
manu: Want to make sure there is agreement on convergence
JoeAndrieu: I want to adjust the proposal
JoeAndrieu: We've had some conversations in these meetings, but haven't talked to DID Traits representatives.
JoeAndrieu: I think the proposal should be about working with DID Traits team to find a way to import traits as criteria.
denkeni: I think the DID Traits is from DIF. The documentation is licensed under CC license. W3C has different license. We need to ensure license compatbility, so make sure the transition is smooth.
<Wip> w3c/
Wip: There is an open issue from DID Traits in DID extensions
Wip: Wanted to highlight this in case people didn't know
ottomorac: I also want to make sure we align with the DID Traits team (JC as main editor).
markus_sabadello: How would you deal with the fact that traits are boolean values and not a range of values like are in the rubric?
JoeAndrieu: In the Rubric, when you define a criteria, you list a question and possible responses. It's possible to have true/false responses.
manu: +1 to ottomorac, sounds great.
manu: I'm a bit concerned if Rubric and Traits continue to exist separately, could cause confusion.
manu: I feel JC and ottomorac have done great work and we should integrate that
manu: I'd like to make sure we have agreement on this path forward.
<Zakim> JoeAndrieu, you wanted to mention "truth"
JoeAndrieu: I agree DID Traits has tried to have hard objective evaluations. Truth is always subjective.
JoeAndrieu: Humans experience what our senses tell us, senses can lie.
JoeAndrieu: All systems of truth we depend on have some mechanisms to review, e.g. courts or scientific reviews.
JoeAndrieu: In terms of scope, I'm not seeing a big disconnect.
Wip: Maybe we should first engage with JC before passing a proposal.
ottomorac: That's also my thought, sit down with me and JC to figure out how they fit together.
ottomorac: Also +1 to manu, we don't want to have multiple DID comparison framework, would favor some kind of unification.
manu: +1 to ottomorac. I don't disagree with JoeAndrieu's view of truth, makes sense.
manu: There are certain things that are less subjective and less objective.
manu: If we feel these are different, if ottomorac and JC agree, with could also publish DID Traits as a Note, but I'm also confident we can fit them in the same document.
manu: I'm looking foward to give DID method authors the ability to specify the traits of their method.
<Zakim> JoeAndrieu, you wanted to say we could bring Otto & JC over as co-editors
<denkeni> That’ll be great!
JoeAndrieu: One option is to bring ottomorac and JC as co-editors and bring their traits into the same document. Could be a possible way forward.
<JoeAndrieu> PROPOSAL: Work with DID Traits editors to find a way to import as DID Traits criteria on an ongoing basis, subject to editor's curation and W3C IP requirements
<ottomorac> i like the sound of that
<Wip> +1
<manu> +1
<denkeni> +1
<JoeAndrieu> +1
<JennieM> +1
<PDL-ASU> +1
<danpape> +1
0
<TallTed> +1 (import as Rubric criteria)
<pchampin> +1
<PDL-ASU> +1 to the language change and +1 to the proposal with it
<ottomorac> +1
RESOLUTION: Work with DID Traits editors to find a way to import DID Traits as Rubric criteria on an ongoing basis, subject to editor's curation and W3C IP requirements
Wip: Thanks JoeAndrieu
Wip: Next time we'll have a normal agenda about DID Core and DID Resolution
<Wip> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/