Meeting minutes
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)
… then problem details, did rubric, and traits discussion.
… over to you, Otto
Horizontal Review Update
ottomorac: first topic, brief update on horizontal review
… we had a conversation to bring somebody in, I think Will at IIW had the conversation, but we decided not to
… but anyways let's keep the topic in the agenda, to measure progress, to figure out the next steps
… I'm assigned to work with Marcus on this, for the DID Resolution side
Wip: I'll help out on the DID Resolution side
… I've just been diving into familiarizing with issues. and started working on an Explainer for DID Resolution
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
<Wip> did-resolution issue is here - w3c/
manu: 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
… so, that's what I'm looking at right now
<Wip> did-core is here w3c/
manu: I don't expect it to take too much time
… one suggestion to Otto and Will -- deal with the easiest groups first.
… 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'
… Internationalization one will be next best. we do have some considerations, but should be fairly easy
… and then Security and Privacy. and do TAG last, since they require the most amount of new content
… it all doesn't have to be done at the same time, you can stagger it, they're not tied together
ottomorac: thanks Manu. I'll get started on this with Marcus
… next one is - the first PR we want to review
Simplify abstract data model and specify one concrete representation
<ottomorac> w3c/
ottomorac: this one is -- so, we said we'd try to eliminate the abstract data model, and follow the CID spec (establishing the algorithm)
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
… so, I'll merge it by the end of the weekend
… I think it's fine as is, I don't think it'll blow anything up
… just to be clear, there are not supposed to be any normative changes (rather, no change in functionality at all in DID implementations)
manu: Marcus, I tried to re-do the image (the diagram)
… and tried using Inkscape, and no luck rendering it
… which app did you use?
markus_sabadello: I used LibreOffice Draw I think?
… I have the source files for all of these, I can send you source files. Or I could update them
manu: source files would be good, we should check it into version control
markus_sabadello: yeah, I ran into some problems as well
manu: yeah, just raise a PR to check in the source files
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
manu: ok, sounds good
… 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
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
manu: I see ok
manu: I'm trying to head off comments on "CBOR is illegal" etc.
JoeAndrieu: well that's the point though - it's not a legal over-the-wire representation
… if you want to call out internal, that's fine
pchampin: I thought I'd put a comment on the PR, but looks like not
… I want to recall Ivan's concern about 'generalized JSON-LD processing'
… I looked at the CID document
… and the source document actually distinguishes normal JSON processing from generalized JSON-LD processing
… the 'generalized' part seems very odd to me
… maybe I should try to propose a fix
manu: yeah, this is where this PR is difficult
… since we can't make Class 4 changes, I can't quite say what we want
… we can't get rid of representation changes, since there are normative statements that involve them
… so we can't remove those
… so I had to keep representations language around. we're trying to get it down to just _one_ JSON representation
… and the generalized processing thing is just trying to say -- don't break JSON-LD processors
… you can go field by field JSON processing. but your output shouldn't break JSON-LD
… that's the consensus we were able to get
… for people who just want to look at the JSON, look at the type, do some processing
… 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
… and that's the language that we reached consensus on with Google and others, who are generally against polyglot processing
… so that's why -- we're trying to not change anything normative.
… with a JSON mechanism, but is 100% compat with JSON-LD
… which would result in no Class 4 changes
ivan: to me, the term 'generalized JSON-LD processing' at that point doesn't bring anything
… that I wouldn't have just by saying 'JSON-LD processing'
… the latter has a clear meaning, via the JSON-LD standard
… the current language uses the term 'generalized JSON-LD proc' _in contrast_ with the type-specific thing
… I don't quite know how to put it clearly, but..
… somehow, I don't know what to do with this term
… I'd simply remove the 'generalized' term
<pchampin> in fact, the text says twice "generalIZED json-ld processing" and twice "general json-ld processing"; I prefer the second wording
<Zakim> manu, you wanted to note that Dave has strong feelings about this. :)
manu: Dave Longley had some pretty strong feelings about this, I'd hesitate to change it
… and I do think Dave has got a point. there are the algorithms in the JSON-LD spec and API spec.
… 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
… because you can ALSO do non-generalized JSON-LD processing, you can do type-specific
… so, it's ok to not use a JSON-LD library to process the document
… so, one class is - 'generalized JSON-LD' is you're using a 100% standards-compliant JSON-LD library to do processing
… and the OTHER approach is you don't have a JSON-LD processor, you can do whatever manual processing,
but as long as the outcome is semantically the same, that's important
ivan: ok, let's move it to the PR discussion
… I'm not entirely convinced
manu: if there's a better language we can use.. hopefully this is a future JSON-LD WG discussion
… there are people that deeply hate JSON-LD libraries, and they're insisting that it's the only way to get proper output,
… and there's another group saying -- no, you can just treat it as JSON, etc
… so, this needs better language.
… and the best language so far was from the VC WG, which Google said they'd be ok with, etc
ottomorac: thanks, we'll come back to this.
DID Resolution: Consider use of "Problem Details" in case of errors
<ottomorac> w3c/
ottomorac: on this PR, we said initially that it's a good idea to settle on some problem details,
… there was some agreement to put it in the spec
… not sure if Manu had a chance
manu: no, I've not had any time, and forgot completely about it. it's on the queue
ottomorac: ok, if people agree with the issue, we can just move on
Wip: I thought I'd take this on, Manu.
… the issue is adding Problem Details to define errors
… the DID spec just has a generic 'error' property and string name
… 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
… for backwards compat
manu: I might be confused.. the Problem Details thing is on the DID Resolution spec
… and we're not bound to any class of changes there, since it's new
… we're also defining a vocab for resolution, right Markus?
<Wip> thats true actually
manu: I know that, Ivan, somewhere on the internet, there's an issue about needing a vocab for DIDs
… anyways, the Problem Details enums go into one of those two
… but neither one of them are in theory normative
… so we just need to figure out which vocab doc (DID or DID Resolution)
… the Security vocab might have some very generic problem types we might want to reuse?... looking..
<ivan> I think Manu refers to this: w3c/
manu: stuff like 'invalid controller' etc
… 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
… does that give you a clear path forward?
Wip: kind of, I want to hear what Markus has to say
markus_sabadello: in DID Resolution, we have a JSON-LD context, we don't have a vocab
… 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
… only issue is -- we have already defined a few error codes in DID Core 1.0
… so we're somewhat bound by that
… like 'invalid did' and 'not found'
… and they're capitalized in a different way than in the Problem Details and CID spec
… so that's the only remaining question - how do we align/reconcile
<Wip> +1 that is where I am confused too
ivan: manu, you opened the floodgates
… there are several things here. yes, first of all, we need a proper vocab for DID Core,
… and I raised an issue several weeks ago on this
… we have the tools inherited from the VC WG to do that, so it just must be done
… 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
… the normative definition must be in the spec
… DID Resolution -- there are two things to be answered
… first, I think it was an issue discussed last week, do we really to use JSON-LD in the DID Resolution spec, or not?
… because if we do, then of course we need a vocabulary, just like DID
… if we don't need to use JSON-LD in the Resolution spec, then it's moot
… 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
… 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
… re JSON-LD and DID Resolution, my personal belief is that it's unnecessary / uninteresting, we don't need it
<Wip> https://
Wip: great, this is less complicated than I thought
<Wip> https://
Wip: we do want to take the 3 error codes from DID 1.0
… I thought there were many more
… so, one approach is -- we change all the error codes to be in the Problem Details approach, like the CID spec
… 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
… so, looking for directions from the group
<Zakim> manu, you wanted to note we don't need to use JSON-LD for DID Resolution responses.
Wip: so, like for Invalid DID, we keep the error string, and ALSO define a problem details object for it
manu: going back to what Ivan said, I agree with everything he said
… 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.
… I don't remember if we have a use case for DID Resolution vocab?
… in any case, I think we only need to define a DID core vocab. and it'll have only one entry
… and that's where we'll put the problem detail definitions
… and because it's non-normative, we can just do that, and be ok
markus_sabadello: I added some thoughts on the JSON and JSON-LD question, in the issue that ivan created
… I would prefer to continue to use JSON-LD for the resolution result
… i don't want to repeat the comments there, I'll paste the link to the issue
ottomorac: moving on to the other topic
DID Rubric & Traits discussion
<ottomorac> w3c/
<markus_sabadello> See discussion here about JSON and JSON-LD for DID Resolution Result: w3c/
ottomorac: I'd like to introduce Jan Christoph Ebersbach
JCE: thanks, we continued to work on the DID Traits effort at DIF
… the idea was to provide a list of relevant features or trait that DIDs use, and record them in a machine-readable format
<ottomorac> https://
JCE: we have different traits like Self-Certifying Identifiers, etc
… we thought about how are we going to use this list of traits. and one way we found useful is to create an overview
… to compare different DID Methods
… so the did-traits link has a comparison table that gives an idea of how they can be used
… and I raised an issue in the DID Extensions repo to discuss possible integration of Traits into the extension registry
… so that method authors can record traits in their registration entry
manu: thank you JCE and ottomorac for this wonderful work
… 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
… so that when people go in and register, they can also, through a property called 'traits', list all the traits that apply
… which would allow them to set booleans to true, or whatever it is
… that might be the easiest integration path
… there are other secondary things like - do we want people to be able to select traits, and filter the extensions list?
… but obv we need data to do that
… the question I have for you JCE and Otto is -- how ready to go do you feel Traits are?
… 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?
… those are the open question I have. but the integration feels straightforward and mechanical to me
JCE: the main thing is - we received approval from the DIF WG for the version 0.8
… we're currently pursuing v1.0
… we did receive some feedback, and there will be additional changes to the list
… 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)
… I'd say we've covered a lot of ground with Traits already. and of course want additional feedback
… in the future, the list will be extended, like you said Manu. a good way would be to go through DIF for extensions
… I'm not bound to keeping the Traits spec at DIF
… maybe it'd be easier to integrate with W3C, to have under one roof
<Zakim> JoeAndrieu, you wanted to suggest we should build on the rubric
JCE: but that's more a question for you all
JoeAndrieu: I'm a bit confused by the tone of conversation -- we passed a resolution to explore how to integrate Traits with the Rubric
… we had a good conversation. i think the DID Traits do fit
… for each trait that exists, we can create a Criteria in the Rubric
… I would be opposed to putting DID Traits in to the Extensions registry, and ignoring the work we've done on the Rubric
… I'd like to see how we can integrate the two, before adding to the Extension
Wip: with chair hat off, I agree with Joe
… for example, one of the trait is Multi-Signature Verification method. and if I understand, ANY DIDs can support multi signature
… at least that's how I understand it
… and that highlights a challenge with the DID Traits approach
… that there's just boolean flags to check,
manu: couple of thoughts
… 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
… whether through the Rubric, or as items in the DID Extensions registry
… so we just need to figure out how it happens
… I agree with Will's point -- all these different verification methods, every DID method should support all of thsoe,
<ottomorac> I will note that I agree that this needs to evolve into W3C as well, not sure what form though
manu: so those boxes will always be checked
… I don't view this as throwing out whatever work was done with the Rubric
… I'm most interested in a way for people to filter DID Methods based on features / criteria, at least on a high level
… there's some criteria we just can't make into a checkbox. but some, we can!
… so, any kind of downselecting / filtering mechanism would be better than just a giant list of 200+ did methods
… so, question is - what's the next step for the group?
… does DIF have any interest in handing some of this over to W3C? IP-wise etc
… I don't think there'd be much IP concerns -- it was incubated at DIF, can be handed to the WG, etc
… again, thing I care most about is the end result -- will people have a better way of navigating the DID methods
… otherwise, it'll be overwhelming / not very useful
markus_sabadello: I think both DID Traits and the Rubric are very useful tools for this kind of filtering
… therefore I'd be very excited to integrate it with the Extensions registry
… I admit I don't remember exactly the resolution we passed previously about integrating Traits with Rubric
… I think one of the aspects was - traits has boolean flags, whereas Rubric was more extensive
… I wonder if this integration is -- I understand what Joe is saying about the order of procedure
… but I wonder if there's any downside to integrating Traits with Extensions in parallel to integrating Rubrics with traits and extensions
… regarding contributions from DIF - maybe JCE can clarify
<Wip> These are our resolutions - https://
ottomorac: just to acknowledge the point, Will just pasted the specific link to the resolution
… this was discussed, I remember,
JCE: so, two things - with regards to data collection, the right place is the DID Extensions Registry
… 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
… 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
… next step wise, to me it feels like we should wait for the 1.0 approval of DID Traits by DIF
… 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
… maybe also work on some display / filtering code
<JoeAndrieu> I would oppose integration that didn't enable Rubric evaluations in the same manner
ottomorac: thanks all, we'll continue discussion in the next call
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/