DID WG Topical Call on DID-core Properties and Metadata — Minutes

Date: 2020-06-02

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Orie Steele, Brent Zundel, Manu Sporny, Dave Longley, Tobias Looker, Jonathan Holt, Kaliya Young, Kyle Den Hartog, Drummond Reed

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Tobias Looker, Brent Zundel

Content:

Brent Zundel: we were originally going to be talking about resolution contracts today however some people cannot make it so will instead be talking about did core properties

Manu Sporny: https://w3c.github.io/did-spec-registries/

1. did core properties

Manu Sporny: Thanks brent, so there has been a new did spec registries that has been put out there, I thought it might be best to start out by going through that

Orie Steele: maybe meta data… https://w3c.github.io/did-spec-registries/#created-0

Orie Steele: maybe added to core properties… https://w3c.github.io/did-spec-registries/#publickeyhex

1.1. did spec registries

Orie Steele: based on the last topic call, there was a request to group like items, we have attempted to do that
… after the top level base properties there are the definitions of service
… and then we have the definition of the verification methods

Dave Longley: Verification Methods should be called “Verification Relationships” (there’s a PR for that)

Orie Steele: then we have the different verification methods properties such as publicKeyJwk and other variations
… Then we have the verification method types which are essentially to become linked data crypto suites
… GpgVerificationKey2020 is a good example of an extension
… After these sections we get into other extension points such as did resolution meta-data

Manu Sporny: So I think what we are looking for from the group, is a general feeling for the direction taken
… the editors are happy with current regrouping
… things are essentially grouped as the kind of thing they are, it flattens the landscapes
… there have been things that have been traditionally pushed aside like ethereum address that are now included correct
… it also gives people a clear place where things we haven’t added yet such as did resolution options and possible errors

Dave Longley: great work, thanks to the editors!

Manu Sporny: Nows your chance to object if you are not happy with the direction taken with the restructure of the registry

Tobias Looker: johnathan_holt … how would you like me to represent this w.r.t to CBOR?

Manu Sporny: We have a column reserved for the property definitions that is currently empty that we would love to see populated with a clickable link with how that is represented in CBOR

Orie Steele: I think the idea is there is a clickable link that takes you to the definition of the CBOR structured representation
… ideally something that is machine verifiable
… it may be handy to have a separate specification for CBOR only definitions and link to from the registry

Jonathan Holt: ok I think I understand how this would work
… let me give it a ponder, some of these things will not map directly to CBOR, there may be a different way to represent it as CBOR with semantic tags

Orie Steele: if we can leverage that then that would be great, by registering semantic tags

Manu Sporny: I’m not hearing any objections to the general direction around the registries restructure

Tobias Looker: .. with that said, did core properties, we could start out talking about metadata and what the types of metadata there could be, or we could talk about specific properties that could be taken out of the spec, what would people prefer?

Drummond Reed: Metadata

Kyle Den Hartog: mics not working

Kyle Den Hartog: will type here

Kyle Den Hartog: preference is to have an understanding about core properties, specifically the proof purposes as I was getting ready to write a section on that

Dave Longley: if removing things goes quickly, +1

Daniel Burnett: brief metadata, then move on

Brent Zundel: +1 to core properties

Kyle Den Hartog: If we just spend a few minutes on that I’m happy to move to metadata after

Orie Steele: +1 to core props first

Daniel Burnett: don’t care about order. do core props first if more support

Dave Longley: whatever we think will go the fastest I’m +1 for

Orie Steele: I think core properties might be straight forward to get through, so would like to go through and point out which are likely to be removed and which we need to put more concrete around

1.2. core properties

Manu Sporny: So we are going to look at the did core spec, we are going to jump around with the properties

Orie Steele: +1 remove the proof property!

Dave Longley: +1 to remove proof from did-core

Manu Sporny: there is a suggestion that section 5.9 proof is to be removed and that every did document

Orie Steele: Proof is now a method specific protection mechanism…

Kyle Den Hartog: +1 remove proof

Manu Sporny: instead how things have evolved is the proof property is not exercised by most did method implementors, proof has become something that is not in scope for the did core spec

Dave Longley: and you may use proof and wrap a DID Document in some other container that expresses meta-data about the DID Document … all valid uses of proof but it doesn’t belong in did-core

Brent Zundel: +1 to remove proof

Orie Steele: Keep proof here: https://w3c.github.io/did-spec-registries/#proof-0 … link to LD security / vocab for definition.

Manu Sporny: the suggestion is we do talk about proof in the did spec registries but it doesn’t go in did core, as it is about protecting the did document which can be done in a variety of ways, e.g a JWT
… so the suggestion is to remove proof from the did-core spec

Brent Zundel: proof removal PR: https://github.com/w3c/did-core/pull/305

Manu Sporny: it could be that a part of the resolver meta-data you might get a proof element back
… I think the assertion here is we are going to remove proof from the did core spec, is there going to be any objections

Drummond Reed: This isn’t necessarily an objection, but if people want to use proof they would have to define it

Orie Steele: they can use security vocab, and see the definition for it in did spec registries.

Manu Sporny: The registry would still define the proof term instead of it linking back to did-core is that it would link to linked data security definitiomn
… if it is in the spec registries then the term definition would still be shared

Drummond Reed: ok thanks for the clarification, we are removing it from did-core but it will still be captured in the did registries and link to the definition supplied by linked data security

Jonathan Holt: so what happened to proof anchor

Manu Sporny: you mean the literal text, proof anchor?
… if you want to include in did-core, you could start off by proposing its addition, otherwise create a specification for it and apply for its addition to the did spec registries
… good news about the registries is that it is a fairly level playing field for people that want to extend the ecosystem
… the other properties up for review are “Created” section 5.7 and “Updated” section 5.8 fields
… these now fall into the category of meta-data

Orie Steele: remove meta data from the did document… but it in the method resolver metadata…

Kyle Den Hartog: +1 to moving this to metadata section of the registries

Manu Sporny: these two fields now probably belong in the meta-data not in the did-core specification

Dave Longley: for the minutes, a “proof anchor” could just be modeled as another proof with a type that indicated it was some kind of anchored proof and properties that expressed where it’s anchored, etc.

Manu Sporny: as you can see in did spec registries we have defined these here
… we would probably move the sections for created and updated to the resolution meta-data section

Dave Longley: +1 to moving those properties to meta-data

Manu Sporny: any clarifying questions?

Drummond Reed: Are we saying the same thing with these properties as we were with proof?

Manu Sporny: we are saying something slightly different, we are saying they would shift into a section probably call did document meta-data section

Drummond Reed: ok great i’m on board with that

Kyle Den Hartog: There was a PR about verification method and about renaming publicKey which was of interest to me and I would like to know about the general thoughts

Manu Sporny: ok lets go there next but first is there any objections about created and updated?
… ok great lets move on
… so there is a question about we may want to take the public key property and rename it to verification method
… public key is a very specific verification method and so why would we have a special bucket for it
… is this proposal clear?
… do people have any strong feelings about this

Orie Steele: I’m in favor of the proposal, but I feel that we should mark publicKey with some note… and keep it

Kyle Den Hartog: I’m in favour of supporting this, I’d also like to constrain it, i’d like all verification methods are defined in this section rather than repeated

Kaliya Young: I think this is connected to the conversation with john callahan and eric welton about how do folks unlocking their keys with biometrics

Orie Steele: its DPKI… that does not return public keys :)

Dave Longley: we do one better than public keys, we have verification methods :)

Drummond Reed: I get the argument, however I have to go on record with saying we have created the notion that a did abstracts a public key and this revists that

Kaliya Young: that also makes sense drummond

Drummond Reed: Thanks, I just had to share that somewhere

Jonathan Holt: I think public key is so ingrained in this infrastructure and hence should not change it
… if there is a biometric method there would be its own spot in the registry

Kyle Den Hartog: would it be useful for us to have a property under the verification method such as public key to preserve this clarity

Manu Sporny: I wanted to address, something that drummond said, I think the relationship to publicKey is important and we do need to preserve this

Orie Steele: you will be able to point to publicKeyPem, etc…

Dave Longley: every example will say “publicKeyBase58” or “publicKeyJwk” on that slide

Manu Sporny: but I dont think we need a public key property to do this

Drummond Reed: I’m good with it; it’s just mostly an irony that the bucket won’t be called “publicKey”

Orie Steele: I think one of the things we are going to see properties in the did-registry in terms of how it is used, and I would say we will have to keep the property anyway because it is so ingrained

Dave Longley: +1 to a note under publicKey that says “use verificationMethod instead and keeping publicKey because it’s in the ecosystem already

Manu Sporny: +1 to set precedent where publicKey is deprecated

Drummond Reed: +1

Dave Longley: +1 to setting precedent as well

Kyle Den Hartog: +1

Orie Steele: the JOSE registry has a recommended vs optional and perhaps we should include something like this in the did spec registry

Drummond Reed: if public key is still in the registry and the historical perspective is preserved then I think yes we could work with that

Manu Sporny: ok so I think that is the discussion about where the public key is going

2. things to chew on

Manu Sporny: capability invocation and delegation that are missing from core properties, they are in the security vocab but we may want to include these in the did-core spec

Dave Longley: “verification relationships” (not methods)

Manu Sporny: dont have to have the debate today but we believe we have two did methods that already use these terms

Dave Longley: capabilityInvocation/capabilityDelegation are for “doing things”/”taking actions”/”performing operations” in a cryptographically secured way

Kyle Den Hartog: first I saw that it was named verification methods or proof purposes?

Orie Steele: https://w3c-ccg.github.io/security-vocab/#capabilityInvocation

Orie Steele: https://w3c-ccg.github.io/security-vocab/#assertionMethod

Dave Longley: they are called verification relationships

Kyle Den Hartog: {

Kyle Den Hartog: we have got verification methods and that is where the public keys to live, then we would add a seperate property for the verification relationships which would have numerous key value pairs for the different verification relationships defined in the did document

Brent Zundel: tplooker_: I created an issue where we can discuss this

Kyle Den Hartog: https://github.com/w3c/did-core/issues/294

Manu Sporny: tplooker_: The issue in discussion is 294

Tobias Looker: issue 294. the conversation is attempting to tease out, what lives at the core of the data model?
… is it verificationMethods and then a flat map of services?

Manu Sporny: tplooker_: The conversation was less about a disruptive change, I have reservations about doign that, what is the clear conversation about what lives at the core of the data model? Is it verification methods and flat map of verification relationships and services, or is there any way we can add clarity, when people are extending it, that they extend it in ways that we expect.

Tobias Looker: do we provide guidance on how to extend it?

Manu Sporny: noting we have 1 minute left lets take the conversation to that issue

Tobias Looker: New found appreciation for scribes :)