DID Working Group F2F — 3rd day — Minutes

Date: 2020-01-31

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Ganesh Annan, Yoshiaki Fukami, Brent Zundel, Kaliya Young, Eugeniu Rusu, Manu Sporny, Justin Richer, David Ezell, Markus Sabadello, Kenneth Ebert, Tobias Looker, Michael Jones, Drummond Reed, Yuwen Zhang, Joe Andrieu, Yancy Ribbens, Oliver Terbu, Pamela Dingle, Christopher Allen, Charles Cunningham, Joachim Lohkamp

Regrets:

Guests: Eric Welton, Carsten Stöcker, Juan Caballero

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Kaliya Young, David Ezell, Drummond Reed, Brent Zundel, Juan Caballero, Pamela Dingle

Content:

Ivan Herman: Meeting slides: https://tinyurl.com/didwg-ams2020-slides

Brent Zundel: outlining agenda

Brent Zundel: Nicole, if you could introduce yourself here that would be great

Daniel Burnett: the last day of a face to face meeting
… does anyone need to leave early - yes after use-cases
… everyone knows it is the last day so we are going o talk about interesting
… thanks Kaliya for scribing
… we are not expecting that intense focus
… hopefully it will be a little more open and calmer

Yuwen Zhang: I am from the China Academy of Information and Communications Technology.

Daniel Burnett: welcome zhangyuwen we are happy you are here!

1. Matrix Parameters

Ivan Herman: See slides in the deck.

Markus Sabadello: matrix parameter is not used that much in the specification it is called DID parameter.
… slide 151
… TBL had this idea long ago
… I will share how we have them (wasn’t my idea)
… in order to explain would like us to think of DIDs as a new building block for the web itself - we tend to think of it as something we need for some use-case, address for VCs, a look up key for a didComm session.
… lets think of it as a new type of address for web itself.
… we need a public key and service end point and not much else
… I could have many services in my did document - it is a URL and it could link a list of services to another URL not all necessarily tightly integrated with other features of the DID.
… I could use my did document as a set of slides
… slide 152
… it is an index of things social network service

Kaliya Young: slide 153

Markus Sabadello: web linking - one url linking to other URLs is a fundamental feature of web … number of ways to implement
… not only used for technical links
… in Indieweb it is a personal identifier - linking to micro sites and other profiles.
… this has nothing to do with LinkedData or RDF

Kaliya Young: slide 154

Markus Sabadello: lets look at another feature - PURLs - persistent URL that doesn’t change but the place it points to will point at
… people invented need because wanted location independent. have been criticized because They are still tied to a network location.

Kaliya Young: Slide 155

Markus Sabadello: there is also a feature called partial redirection - add path query or
… that path “stays”
… it will be added to the redirected URL
… information space is now included in
… what does this remind of us
… DIDs are very much like this if I have a DID and de-reference to DIDComm, etc.
… traditional purls are persistent because of agreements
… with DID persistence is guaranteed with cryptography and root of trust

Kaliya Young: slide 157

Markus Sabadello: you can add path query and redirection

Kaliya Young: slide 158

Markus Sabadello: difference with DIDs…. DIDs support linking to different services…
… as part of the innovation we couldn’t use existing way to do this.
… initial idea to use semi-colen to add this extension

Daniel Burnett: clarifying questions

Samuel Smith: I think a dynamic DNS like a Purl dynamically resolvable stable identifier - redirects whole name space.

Kaliya Young: slide 159

Markus Sabadello: example of how this would work
… here it is already a matrix parameter
… instead of adding : and then a service.
… start with did URL
… it gives you portability - stable identifier that is independent of network address

Tobias Looker: clarifying question

Markus Sabadello: DID X
… slide 160 to summarize it combines features of two very interesting concepts in web architecture
… gives us all the features that did provides, cryptographic verifiablility, root of trust,
… on personal Self-sovereign name space that gives another web address that you want
… to compare this with query parameters
… the query parameters pass parameters into the DID resolution process
… just like the HTTP specification doesn’t tell you want to do with paths quieries and fragments
… like dynamic DNS - urn resolution - R components, q components f components
… do you want to use a resolver in the Uk (on slide 162)
… the different query components are added to URL
… this is where we came up with this - we wanted a way to select the service. other parameters
… version ID and Version time if you don’t want to resolve the current did document - version 4 or two months ago
… you might have a VC from earlier and want an older key
… want a version of the did document path query and fragment

Kaliya Young: slide 163

Kaliya Young: slide 164

Markus Sabadello: similar to - hash value - separate value - hashlinks is part of CCG work again
… some other matrix parameters that have been proposed over time
… I think we need a registry for this…

Kaliya Young: slide 166 has the potential matrix parameters

Markus Sabadello: input options into a resolver - things you pass separately from the URL
… during dereferencing passes things not all input options have to represented as matrix parameters (did parameters) are part of the URL.
… other things you don’t want that are part of the URL

Markus Sabadello: summary of the issues - not part of the standard URI parsers
… rejected 2 could be parsed with standard URI parser
… entire authority component is non-standard… you have to have some parsing that is custom for the colons.
… I think you can say it is standard anyway or non-standard anyways
… it is to complex
… it does add complexity - no question - but is it worth it
… optional? do we not want it all.
… it is a very old proposal it has not been used in http URL
… we shouldn’t reject because we haven’t really seen them widespread use in URL
… should we use existing “special query parameters”

Markus Sabadello: mentions different existing issues

Manu Sporny: putting services in a did document might be an anti-pattern. don’t know if we have raised an issue about this.
… not to say services are not useful - they are
… talking about use case and then solution to use-case
… use case is solid - concern that I have has to do with the solution
… if I had to hold my nose I could live with them in
… question is there something simpler
… is there any objections to the use-case then it is a question of how we achieve

Ivan Herman: i don’t want to get into standards/nonstandards - that is a minor point
… but I would step back a little bit - stand back look at DID uri structure as it is today
… my understanding is I and any of these goodies - then it is a different DID for a subject…all the security and keys are invalid for that URI
… haven’t found things in document - keys valid? problem with any additional structure - then is something to answer
… what happens with URI and http - URI specification and is very vague path fragment query means
… reference to json, json-ld, cbor then don’t know what fragments really mean. query parameter in URI work anyway we want.
… have the feeling of getting into the details one component - I’m not sure we have a through understanding of these components in the first place

Daniel Burnett: these are sort of an added feature - they are very useful
… fragment processing is done - logically a local thing
… not something that DID methods get to mess with
… DID methods don’t get to define what happens to fragment s(if we are in alignment with uRIs)
… could go straight to IPv6 static
… disrupt DNS zero trust
… establish control authority - fixing the whole in DNS by doing it this way
… layering - control authority, then indirection

Tobias Looker: if we are using DID URL and different did of different schemes did URI - to URL and define behavior and de-referencing.
… if you dereference and don’t know how to respond

Markus Sabadello: now did resolution specification defines what you do with the parameters.
… a way we can simplify this - how relative URIs work - take what is in DID URL - apply existing relative URI - relative to the service end point - don’t have to invent anything new

Joe Andrieu: confused between difference between service parameters and matrix end points.
… not defined in the use-cases document.
… what was maintaining the entire path and query
… in we re-direction doesn’t maintain ???
… conflating URL - header with this

Eric Welton: see as potential to maintain persistence
… there needs to be all kind of extensibility
… that is divorced from trust/control thing are they appropriate use-cases in did core spec

Drummond Reed: to ivan’s point the DID itself - always identifies the DID subject
… DID is a uri
… anything beyond that we call a “did url”
… the components in 3986 are very clear there - DID are a new type of authority component. single strongest reason to put as part of authority component
Markus Sabadello: also wanted to comment on what Ivan said - does create a new identifer - doesn’t mean the did subject changes. perfectly fine to have multiple different identifiers that point to same individuals.
… agree only authority component we can control.
… we could control the query
… parameters - we could do it. don’t think we should do it.
… leave it undefined for method developers - concrete example of why it could not work.
… could only go through matrix parameters
… agree with manu shoudl ask if we want to support use-cases

Michael Jones: missed a bit
… when used with oauth has particular meaning - establish a registry with query parameters that are used with DIDs so common understanding thus not

Michael Jones: https://tools.ietf.org/html/rfc6750 is an example of a spec defining a query parameter: access_token

Manu Sporny: so not hearing - not a valid use case

Michael Jones: We should establish a registry for query parameters used with DIDs, per our decisions yesterday

Joe Andrieu: can’t comment on use case I don’t understand

Manu Sporny: paths - are a good use case - please disagree?

Michael Jones: Then we are facilitating use of query parameters with DIDs in an interoperable way

Manu Sporny: if no one disagrees - discussion about how we achieved
… would like to understand markus opinion better

Joe Andrieu: paths is not a use-case doesn’t tell me the value for the end user and why paths create that value - it is a “wouldn’t it be nice to have it?”
… other then drop-box use case that hasn’t been written up

Joe Andrieu: 3.2. from the URI RFC: Authority : Many URI schemes include a hierarchical element for a naming authority so that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further).

Joe Andrieu: we are mis-speaking about authority in DID. method is the authority
… when you go look up the method - that is the authority part… if we want to understand how we fit in standard parsers

Ivan Herman: didn’t understand what drummond is saying
… the fact I can be identified by several DID - this is obvious - I don’t know DID..method…blahblah blah… semicolon - who is subject of “that” did. cause it is different DID with … E.g., in Semantic Web they are very sensitive about differences of a URI even if, as URL-s, the refer to the same resources. About all syntax we have to answer this question

Drummond Reed: to joe’s point - in RFC 3986, The URI Specification, Appendix A, first line: URI = scheme “:” hier-part [ “?” query ] [ “#” fragment ]
… in ABNF in our current spec - doesn’t refer to anything beyond did:namespace: method specific ID (single character beyond) then it is DID URL - then you are identifying another resource - may or may not be subject

Ivan Herman: it isn’t in the document - it is the ABNF

Eric Welton: like what drummond said - brings a 2nd class of use
… is it a CORE part of DID
… concern about location of use-cases in this
… don’t take as substantive

Markus Sabadello: not clearly specify what that identifier is
… would have to specify
… re what mike and manu raised special use-cases

Samuel Smith: would ask group to step back on this topic - why we are here current security model is broken - how do we fix the security model of the web - we have opporutnity - address problems web has

Manu Sporny: I feel like we are having two totally different discussions - most people trying to solve the use-case but it isn’t clearly defined
… can we just talk about the use-cases
… there is one the look up use-case
… slide 169 says do this use-case with

Daniel Burnett: we will finish queue and then define use case
… the authority part of the URI - joe you said it said something and the text disagrees
… many schemes will - will come up with an authority part that does these things
… we may have done that via the did method - the URI doesn’t say there must be an authority part of a URI

Drummond Reed: it is the first line of the spec
… hierpart - is required
… is an optional part - the authority part
… when it comes to use-cases services and service indirection - we have many other did parameters we have been talking about. The sovrin community we must have versioning of DID documents and consistent way of doing it and it can’t be in the fragment - if query parameters.

Joe Andrieu: so to respond to dan’s comment - didn’t say we have to have an authority component and the hierarchic is method and method specific identifier
… I believe we have an authority part that isn’t named in the spec. One of the issues with the us-case the path fit without a service end point there is no concensus
… the current proposed rule is that path query part and path - doesn’t work (not sure exactly.. )

1.1. use cases

Markus Sabadello: use-cases not mechanism parameters - slide 159
… persistent web address
… points at the first part of the resume section - move file to hosted service to self-hosted service don’t have t update the document. query and matrix don’t get cancotenated -

Joe Andrieu: i call this the drop-box use case

Kaliya Young: use-case slide 170

Joe Andrieu: use case name “movable “dropbox””
… key thing about this use-case is that you want to be able to append a long path and move the route around
… i can have a service for my business card… if you want a complicated path structure maintained. go to my did and get the avatar…
… my understanding is that you want to be able to move it - you can’t predict the future endpoint in the future - don’t think it works it brittle

Tobias Looker: bootstraping communication with did subjects
… start with DID and VC rendered human friendly information

Carsten Stöcker: IoT data streaming - work Sam has done - i can give data stream - within that hash service
… did for entire data stream - every data within is hash - then can reference within the stream

Drummond Reed: joe’s concern about possible brittleness DID based URL
… use-case for portable files systems or data hierarchy if we support this use-case for data portability in general and data authority - did based data portability

Samuel Smith: re-inforce what drummond said - persistent identifier or an indirectable - the motivation is that the value that an identifier has in a social construct with respect of the user in control - user is in control.
… without this we haven’t given people self-sovereign - control of their own data

Kenneth Ebert: as verifer I might want to access a point in time - so can access

Daniel Burnett: looking for more use-cases

Manu Sporny: I think we only have one use-case that can’t be solved with mechanisms we have - did based portability so I think I agree with drummond and sam
… having a service in your did doucment can serve many of these in
… iot - can be done with .. (scribe didn’t get it)
… looks like we have to debate - rest we have ways to solve

Eric Welton: I think this is a use-case heard on did resolver calls - reaching into crypto material
… keys and key materials … (scribe missed)

Joe Andrieu: data portability is hirerachy and incorporates data streaming
… ken I don’t understand value proposition

Markus Sabadello: made another slide 160
… now I understand the potential brittleness - withouth adding appending paths - if service type is the same … hosted next cloud - changes location then it is the same
… then I want partial re-direction

Samuel Smith: +1 joe hierarchic structure portable hierarchy

Oliver Terbu: I while ago question on should we add transform keys matrix parameters … I would like to be sure this use case is still possible.
… use case that I see

Kenneth Ebert: benifit is to get the correct document at a particular point in time - valuable use-case so use

Joe Andrieu: current did document is the authoritative one and what you are doing is something exceptional
… less then 15 min less - no reslutions or decisions - was valuable…to engage with what are the use-cases people who disagree that these use-cases are sufficient to motivate those features

1.2. discussion closure

Daniel Burnett: who hear believes that there is at least one use-case there for them motivates the need for the matrix [did] parameters feature

Markus Sabadello: +1

Ganesh Annan: +1

Joe Andrieu: -1

Manu Sporny: +1

Oliver Terbu: +1

Kenneth Ebert: +1

Yancy Ribbens: -1

Drummond Reed: +1

Samuel Smith: +1

Michael Jones: -1

Ivan Herman: 0

charles: +1

Justin Richer: 0

Eugeniu Rusu: -1

Carsten Stöcker: +1

Tobias Looker: +1

David Ezell: 0

Brent Zundel: 0

Manu Sporny: For the record, I think there is only one use case

joachim: 0

Markus Sabadello: See the Slide that explores if/how the PURL data portability use case can be achieved with query parameters

Drummond Reed: Can we have Markus present his slides?

Kaliya Young: (chairs confering)

Brent Zundel: what are some other mechanisms that can solve it

Joe Andrieu: ealier touched on conflation between service end point parameters - didn’t undersand they are merged into a single context
… haven’t heard any of these map into a matrix paramter that isn’t a service use case

Ivan Herman: the ‘hl’ parameter was also an example

Justin Richer: my question to the group is - do we believe that having effectively stable APIs such that query and path parameters will be portable across
… 160 - do we as a working group believe that there are going to be enough cases where I have a something like this -… one hose with a particular path … replicated in same way…is it worth to carry through after the DID URL has been processed

Drummond Reed: would a portability of a blog?

Justin Richer: No blogs are totally different

Daniel Burnett: we still end up needing the usecases that can’t be solved in any other way - to get to that point the existing use-cases solved in any other way.
… not going to happen at this meeting - two things are good next steps for us to do as this toic (eveyrone agrees)
… who wants to lead an issue

Brent Zundel: refining use-cases AND how to solve without matrix parameters

Kaliya Young: Markus and Joe voluneer to pull documents together - when do you want it done by

Joe Andrieu: much of my argument is that it can be done via service end point - matrix parameter.

2. spec structure

Ivan Herman: See slides in the deck.

Drummond Reed: I have produced a “straw-man” to start discussion.
… does this exercise make sense?

Michael Jones: ABNF seems out of place.

Drummond Reed: I added ABNF to help identify the original section.

Justin Richer: need to discuss “new structure” in the context of producers and consumers.
… also what does it mean (e.g.) when processing with JSON-LD. What if there is no @context field?
… it will specific to each representation type.

Joe Andrieu: we need to include the use cases.

Justin Richer: -1 to adding use cases to the spec

Justin Richer: + 0.5 to motivations

Joe Andrieu: +1 Justin_R This would be the distillation of requirements from the use case & requirements doc. not listing the use cases.

Manu Sporny: first time I’ve seen this new structure, but +1 (for either Proposal #1 or #2)
… also like “producer/consumer” idea.

Ivan Herman: one problem with the current document - there is not one place where I can find the terms that are essential and formally defined.
… “these are the terms this specification defines.” Probably goes into the abstract data model.

Brent Zundel: why is it different from the terminology section?

Ivan Herman: The terminology is different. That contains, e.g., the terminology “DID”. But there should be one place for the definition of properties like, e.g., subject or publicKey

Oliver Terbu: +1

Tobias Looker: (recommending a rework of the new structure). terminology, syntax, datamodel
… should have this overarching flow.

Markus Sabadello: I like the new structure. There will be multiple extensibility models. The term seems to imply there is only one model.

Justin Richer: +1 to mechanisms

Samuel Smith: I think 4, 6, and 7 should be a new section “DID Documents”.
… extensibility above abstract data model.
… then create a new section “Did Documents” and put 4, 6, and 7 under that.

Justin Richer: a good first step, but we need to consider breaking into multiple documents.

Joe Andrieu: We are missing the relationship between DID and DID Documents. A section 3 for “overall architecture” would help clarify.

Michael Jones: I strongly object to the ‘s’ at the end of mechanisms.
… we agreed to exactly one such mechanism for interoperability. Private extensions not affected.
… registries are the interoperable extension mechanism.

Justin Richer: +1

Brent Zundel: how about just “extensibility”

Oliver Terbu: extensibility belongs under “DID Documents”.

Michael Jones: I believe that the extensibility section should describe that we use registries to facilitate extensibility and not define or describe any other mechanisms

Tobias Looker: extensibility comes too early in the list, before we define what we’re extending.

Kenneth Ebert: +1 to Tobias comments on extensibility coming after the definition of the thing you are extending.

Oliver Terbu: +1

Tobias Looker: “extensibility” can appear under other topics in context.

Markus Sabadello: it seems like a contradiction to say there’s only one extensibility mechanism when we know there will be others.
… propose to add back the word that drummond just deleted.

Michael Jones: So that we’re clear, this section should also include this statement at the end “Other extensibility mechanisms MAY be used by particular organizations or communities but defining such mechanism is out of scope for this specification”

Kenneth Ebert: +1 to Markus suggestion that we define how extensibility works that may not be non-global.

Daniel Burnett: the chairs believe from the conversation yesterday, people who want more extensibility mechanisms can do that. We really don’t want to restart that conversation.
… will anyone raise a formal objection?

Markus Sabadello: I will object if other extensibility mechanisms are out of scope.

Daniel Burnett: I’m asking whether the work “mechanisms” has to appear after “extensibility.”

David Ezell: (no responses)

Manu Sporny: going back to Justin’s comment about multiple documents.
… I’m a strong -1 for splitting up the spec.

Samuel Smith: +1 Manu

Manu Sporny: I hear tons of complaints resulting from splitting documents.
… (not reopening the extensibility debate) I think both sides have a point and we’re proceeding in good faith that we’ll come to consensus.

Daniel Burnett: -1 to moving sec and priv sections

Justin Richer: -1 to putting sec/priv forward

Ivan Herman: normally “security” and the “privacy” sections usually appear towards the end of a W3C document as in this structure. But we may want to see whether security and privacy should appear earlier in the document in this specific case to give the required emphasis, especially for this topic.
… also, as we said yesterday, it’s “DID Information”; “DID Document” gives the wrong impression.

Samuel Smith: Overall architecture should include security and privacy

Brent Zundel: -1 to moving priv and sec sections

Brent Zundel: +1 to renaming DID Document

Ganesh Annan: +1

Justin Richer: +1 to forward pointers (as is tradition)

Drummond Reed: the positioning of “extensibility” is difficult. I’d like to discuss extensibility in the context of the relevant topic.

Joe Andrieu: +1 to inline extensibility

Daniel Burnett: we’re hoping not to be too prescriptive about where we can and can not talk about extensibility.
… at this point the topic is editorial.

Justin Richer: +1 to the chairs’ point

Kenneth Ebert: +1

Daniel Burnett: suggest leaving “Extensibility” where it is, and leave it to editor discretion.
… we would like to move on (group agrees).

Justin Richer: +1 to considering in-line extensibility. In general, it’s easier for people to read a document that goes from concrete to abstract than the other way around.
… I ask the editors to keep in mind that people will be looking for concrete things first.

Juan Caballero: +1 to Justin and Tobias’ comments on prioritizing how most laypersons read specs

Juan Caballero: Sorry, most implementers

Michael Jones: I never suggested that there be only one extensibility mechanism.
… what we did do was explain the “interoperable” mechanism that is in scope for the document.

Markus Sabadello: I think we still have disagreement about those alternatives being out of scope.

Juan Caballero: +1 to tobias’ proposal, slide 177

Drummond Reed: +1

Samuel Smith: (scribe missed - suggestions about adding more detail.)

Brent Zundel: we really didn’t intend to go to this level of detail. I think we’ve gotten out of this section what we wanted.

Brent Zundel: we will submit a PR for what we have, and people can comment on the PR.
… create your own PR to make concrete recommendations for reordering, etc.

Drummond Reed: all I want to do is say this session has been productive. Is it OK with everyone to create a new PR?

David Ezell: (nods)

Drummond Reed: representation requirements - please think about the representation requirements (slide 178)

Joe Andrieu: +1 to representation requirements

Drummond Reed: I already know that this list isn’t complete enough.

Daniel Burnett: propose that as a separate PR.

Christopher Allen: wanted to support Markus position on extensibility. If the one extensibility data model doesn’t allow methods to extend, I like Markus would formally object.

Manu Sporny: With my Editor’s hat off, speaking on behalf of Digital Bazaar, we stand with Danube Tech and will formally object if there is not an appropriate balance wrt. the extensibility model discussed yesterday.

Markus Sabadello: From the abstract/charter: “These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, …”

Michael Jones: all I’m saying is that we agreed on a mechanism. As long as other mechanisms use that mechanism, we’ll be interoperable.

3. Rubric

Ivan Herman: See slides in the deck.

Ivan Herman: See Current early draft for the rubric document

David Ezell: (presents the draft of the Rubric)

Daniel Burnett: keep in mind that converting to Respec must come before Next PWD.
… so timeframe (July) must consider that.

Samuel Smith: I am surprised I didn’t see security model and trust discussed as part of the Rubric

Joe Andrieu: if the issue isn’t specifically about decentralization, they might have been missed.

Christopher Allen: An important discovery is that there is no perfect decentralization.
… compromises are going to be required. Idealism won’t work.

Christopher Allen: The book is https://mitpress.mit.edu/books/protocol

Christopher Allen: sample chapter at http://art.yale.edu/file_columns/0000/8696/galloway-ch4.pdf

Manu Sporny: examples are great and terrible at the same time. My concern is that the examples are going to go stale.

Brent Zundel: +1 to more categorical examples (striking the actual DID method names)

Manu Sporny: there’s also an exclusion of the interests of some groups not here.
… we should censure the ledger names in the document itself.
… it might be useful to have a registry where you can have evaluations - self, third-party, community.

Joe Andrieu: I’m against our hosting evaluations.

Manu Sporny: that’s OK.

Carsten Stöcker: you might get insights on interoperability between did methods.

Joe Andrieu: We might have gotten some insights, but I think we should be more intentional about it.

Brent Zundel: is there a Rubric for the decentralization of how the method is used?
… different use cases might have different decentralization.

Joe Andrieu: the method does give some space for that in the answers.

Kaliya Young: it would be useful to connect decentralization to methods.

Pamela Dingle: is there a sense of how many questions people will answer consistently?

Joe Andrieu: goal is to produce a 2 page summary, so we id try to make it compact.

Pamela Dingle: so how long does it take?

Joe Andrieu: about 1 day.

Drummond Reed: I think that’s about right.

Joe Andrieu: if you have more people involved in answering it will take longer. Teams are slower than individuals.

Ganesh Annan: one day to understand a method in depth, and then have them fill out an evaluation, it’s overly ambitious.

Joe Andrieu: If you focus on the parts important to you, you can limit the time.

Ganesh Annan: it’s also related to how well the did method is defined.

Drummond Reed: first, how will you get this evaluation done (hire an expert?).
… second, don’t just think about individual method authors, think about third-parties.

Joe Andrieu: running workshops to help educate people is a good idea.

Manu Sporny: I’m worried about the time it takes.
… It takes an enormous amount of time. Clients want evaluations but don’t want to pay for them.
… there will be “reverse incentives” forcing people to rush through evaluations and give bad data.
… I realize you can select sections, but we might also want to gives some more explicit guidance.

Joe Andrieu: there will also be people asking peers “what methods do you use.” There’s no explicit evaluation, it’s peer recommendation.

Markus Sabadello: there’s no absolute measure in the result of the rubric, i wonder if there should be a “minimum bar”?
… maybe establish a registry for did methods. Do we want a Facebook method in our registry?

Joe Andrieu: my wrapup, want to turn this over to the chairs and get consensus on an FPWD.

Brent Zundel: we will select editors, etc. as part of that process.

Joe Andrieu: this has been an amazing exercise.

Michael Jones: my experience as an expert for registries, make sure that requested entries are understandable and actionable, but avoid saying “your submission is not good enough.”
… we should welcome all comers as long as their submission is clear and actionable.

Joe Andrieu: I agree with that.

4. Use cases & Requirements

Ivan Herman: See slides in the deck.

Drummond Reed: Joe explained that Phil Archer could not be here today.

Joe Andrieu: The main reason for use cases & requirements is to focus our work and make sure it addresses the actual needs
… It is also to communicate to others the value of our work
… It is also to capture the consensus of the WG
… And to capture requirements
… The current draft was started in the Credentials Community Group
… the use cases document should not talk about specific technology or solutions.
… Currently the doc has 5 focal use cases.
… 1) Corporate Identifiers, 2) Life-long Recipient-Managed Credentials, 3) Prescriptions, 4) Digital Executor, 5) Single-Sign On
… the Digital Executor use case involves long-lived delegations to a trusted party like an executor
… The previous use cases are FOCAL, so each is explained in depth. There are currently five more brief use cases.
… 1) Online Shopper, 2) Vehicle Assemblies, 3) Encrypted Data Vault, 4) Accessing service endpoints, 5) Verifiable Credentials
… The brief use cases are each just one paragraph.
… There are still issues around terminology. The document does share one terminology section.
… There is one outstanding set of issues around roles. The open question is around the role for someone who is using a DID but is neither the DID Controller or the DID Subject.
… The main current task is for contributors to write up use cases.
… Slide 203 has instructions on “How to Help: Brief Uses Cases”
… Write up one specific value-creating interaction. It is not a category, not a list.
… Be specific: make it about a real person with a clear, motivation.
… Describe what they do, doing a real task. Not why. Not how. “Just the facts, ma’am.”
… Be distinct: cover a feature not already covered.
… Slide 204: different possible domains and use cases. Examples: IoT. Crypto. Authorization. Extensibility.12:59:10 <brent> q+ to ask about DID Comms
… Possible Domains and Use Cases (slide 204 in the current slide deck)
… several examples of these brief use cases in order to spur others to submit new ones
… he used the example of a bank who wants to delegate a specific capability to Joe, who can then redelegate to others.
… Joe wants his assistant, controller, and CPA, and he wants all of them to have different permissions
… DIDs can enable all of the parties to a delegation chain to rotate their keys, when combined with other delegation mechanisms
… Joe’s reaction to Brent’s suggestion: “It would almost be as great as keeping the Chair on the queue”

Joe Andrieu: Another example is chain of authority, i.e., having clear delegation chains via DIDs and verifiable credentials.
… Currently, we have nothing about extensibility
… currently we don’t have any innovative examples of extensibility. Joe invites a use case about it.

Drummond Reed: Sign me up for one use case about service endpoints.

Joe Andrieu: Asks for other use cases on service endpoints.

Markus Sabadello: will add a use case about proxy resolution.

Christopher Allen: Was wondering about use cases for BTCR

Joe Andrieu: Asks for everyone’s input about additional use cases.

Ivan Herman: One more very important point to keep in mind: some of us will be involved in presenting DID tech to outsiders. Use cases help very much for this.
… short but clear use cases is really very important for this.

Juan Caballero: +1

Joe Andrieu: Strongly agrees.
… looking for the 1-minute video of a use case that’s very clear for DIDs

Ivan Herman: What is missing also is “How do I use the spec to solve these things”.
… doing that for all use cases in the doc would be very hard, but picking a few and doing that for those would be very helpful.

Kenneth Ebert: had several examples that he thinks he can contribute. One of them was verifiable credentials, but of specific types.
… he will sign up to look at those for healthcare.

Eric Welton: Every use case for naming “things” could be submitted.

Joe Andrieu: Use cases should stress people. Examples of using them for cats is weaker.

Eric Welton: Signed up for a use case about naming cats.

Christopher Allen: Some people have “abandoned” DIDs because they all use cases are around “legally-enabled SSI” (LESS).
… but they are much more interested in true “self-sovereign identity” or “trustless” identity, and so we need them to be “focal” use cases.
… in particular ONE of the five use cases that’s not about legally-enabled digital identity
… also wants to see an example of a use case that’s about enabling something to exist because it’s been given keys.

Joe Andrieu: Does not want to have more than 5 focal use cases.

Brent Zundel: Some of the use cases are not about DIDs so much as about verifiable credentials.
… What Ivan mentioned is more of an “application guide”.

Markus Sabadello: Liked what Christopher Allen said about the “trustless” use cases, but there were some limits on it in the charter.
… such as “I want to avoid paying taxes”. Is that out of scope?

Joe Andrieu: The place to draw that line is “extra-legal”, not “illegal”.
… legality can be tied to a specific sovereign state.
… and no one is advocating anything like that.

Juan Caballero: another terminological tweak: non-state, not anti-state

Joe Andrieu: the Red Cross is a great example. In Joe’s own case, his apartment burned down and the Red Cross showed up to help and did not ask for ID.

Carsten Stöcker: We might want to structure use cases by entity type. People, orgs, IoT objects, physical objects.
… example is giving DIDs to cars. Various autonomic things.
… would like to volunteer to do those.

Joe Andrieu: Yes, those would be great.

Kaliya Young: Speaking for Wireline, they are looking for highly decentralization applications, and I will provide some use cases for those scenarios.
… sometimes those are called DWeb or Web 3.0.
… they are not necessarily engaging, and we are potentially going to miss them if we don’t speak up.

Juan Caballero: Editorial suggestion: maybe better to have a list of identity types (natural person, legal person, machine, software/AI, product (abstract), product (specific)) as a matrix– list for each use case home many are involved, so that people can search/filter by all use-cases involving in in any way

Eric Welton: There should be IoT use cases that do not involve any “agency” of some other authority.

Juan Caballero: +1 to Kaliya’s point about alternative networks and their different environmental, networking, and liability assumptions

Eric Welton: so there needs to be an ability to “point at things” and “name things’ without using a centralized authority.

Drummond Reed: It occurs to me that a compelling use case is something you can only do with DIDs
… Forming a connection between two human beings that can last for all time with no central intermediary
… it was something that has never been possible before

Manu Sporny: I’ve heard a few people say there’s constraints on what we can and can’t do in the use cases.
… for example, creating a new Digital Nation is a real use case.
… and one of the best ways to reach out to those parties is to write up those use cases.
… they should be invited in.
… and Manu would like to see us write up those use cases.

Juan Caballero: +1, lots of non-state people are very active on github, if you leave the issue open they will find it :D

Juan Caballero: particularly since this happened: https://www.theverge.com/2019/4/22/18511088/microsoft-github-tech-censorship-996-repository-china

Joe Andrieu: Wanted to clarify that use cases are not constrained to “what exists today”, but can talk about future situations.

Markus Sabadello: Wanted to endorse the inclusion of VRM (Vendor Relationship Management) use cases.

Kaliya Young: Ambassadorship (for the DID WG) is very important.
… there was an example at a recent conference where a member of our community “overevangelized”.
… we need to be sensitive about others concerns about control and decentralization.

Joe Andrieu: He has not heard anything about vulnerable populations using DIDs.

Samuel Smith: Volunteered a use case in that area.

Eric Welton: Also volunteered a use case in that area.

Joe Andrieu: Was very pleased with the number of new ideas.

Juan Caballero: I would be glad to refine previously-submitted case about anonymous sources and journalist safety

Drummond Reed: Also excited about the non-VC examples that were raised.

5. Metadata

Ivan Herman: See slides in the deck.

Daniel Burnett: explanation of metadata concretization exercise
… I want everyone to give concrete examples of properties (in a DIDDOC), and what their implementation does/will use it for; optionally, also how they get it and where it goes
… [correction: not just properties in a DIDDoc, but also pieces of metadata and debatable things that might be metadata for some but not others]

Joe Andrieu: what you said and the slide don’t line up well?

Daniel Burnett: yup, i’ll edit the slide
… by “come from”, I meant, pre-existing, spit out by resolution process, etc

Drummond Reed: these things we’re brainstorming are all things that end up where? in spec?

Daniel Burnett: it’s things the speaker needs spec’d somewhere, but they might end up in diff places
… or not spec’d at all

Drummond Reed: how’s it go?

Daniel Burnett: one per slide, edit or add, discussed separately

Markus Sabadello:

Manu Sporny: we’re not debating what’s already in the spec, are we?

Daniel Burnett: nope, we’re trying to get clarity on did doc versus metadata versus resolution header question

Manu Sporny: does that cover data inside keys (owner, type)? i have a list of 35 in my head already!

Daniel Burnett: i’m trying to avoid submerged mines and unrecognized disagreements, partic about properties being metadata/diddoc/resolution

Drummond Reed: we might have 100 here pretty quickly?

Daniel Burnett: of course! i just want to identify disagreements

Tobias Looker: start with the controversial ones?

Manu Sporny: +1

Daniel Burnett: no more process questions?

Ganesh Annan: i don’t have a name, exactly
… but I want a timestamp of did RESOLUTION
… (“when it was resolved”)
… 2.) I want a self-attested timestamp about did creation from its controller

Daniel Burnett: process, let’s build list first and come back to why and how

Ganesh Annan: for cache invalidation
… (that’s what i want #1 for)

Daniel Burnett: #1 where it comes from? how’s it generated?

Ganesh Annan: the process ? the resolver?

Justin Richer: that’s who asked, not who answered

Ganesh Annan: then leave it as “the process” for now?
… #2 is for metadata ing things

Daniel Burnett: no
… if it’s proprietary, you can say that, but that’s not much less circular
… let’s add a C subheading for name of proposer to check back after discussion/iteration
… so where’s the timestamp #1 come from, tho?
… where’s #2 come from, exactly?

Ganesh Annan: DID controller is who i mean by “self-attested”

Justin Richer: mime/type
… “document serialization format”, more generally; there are alternatives to MIME
… and I don’t want to assume that’s the best way to know how to deserialize a bunch of 1s and 0s
… i care about this as code dispatch
… it comes from output of resolution
… (not dereferencing)

Manu Sporny: can i put a prop on there that I want RIPPED OUT of the spec
… or at least, ripped out of the did doc
… (i’ll come back to it)
… i want a property that capability can be invoked or delegated
… #1 capability invocation and #2 capability delegation

Joe Andreiu: I don’t speak OCap, please clarify for those of us in the back?

Manu Sporny: key material used to invoke an OCap
… DID controller provides both keys
… directly
… burn: is it a private key?

Samuel Smith: q

Manu Sporny: no, it’s the public key assoc with a private key
… it’s not a valet key, it’s the action of being given the valet key

Tobias Looker: it’s like a fingerprint reader ON the valet key

Juan Caballero: tplooker, not tobias

Daniel Burnett: i’m trying to avoid everyone thinking of DID Controller as an entity

Joe Andreiu: I think you’re worried about a conflation between human user and software agent?

Daniel Burnett: I want to be extra clear here

Joe Andreiu: can we tease it out [ChristopherA: later?]

Manu Sporny: let’s table this for now!

Daniel Burnett: but this clarification is useful to others adding to the list!

Manu Sporny: #2- also can come from any entity

Ganesh Annan: #2 i meant software agent by DID controller

Daniel Burnett: aha!
… this is why I wanted to tease out these differences of assumption!

Christopher Allen: I want a “versioning” assertation by the creator of a DID as to that particular version of the DID
… not its underlying blockchain anchoring, key rotation mechanics, etc
… I am calling it a “Controller Version” , it is from the DID Controller (“a person”), and it’s for the relying party to know what happened if an underlying blockchain changed but without the controller knowing about it or caring
… it’s a trust thing

Joe Andreiu: This sounds like a surprising thing for the human to know or understand?

Christopher Allen: OK, maybe it’s usually the agent, but it’s the agent acting on behalf of the person, as opposed to the blockchain
… #2: I’m calling this one “Controller Redacted”
… you don’t need the public key
… I’m imagining an indirection/minimal disclosure situation
… so that a public key is granted by a DID Doc only after a legit business reason has been proven
… For: Controller to redact/minimally disclose information (i.e. a public key)

Drummond Reed: It’s still not very clear to me, can we rename it or reword it

Joe Andreiu: Controller: [REDACTED]

Christopher Allen: #3: AntiSybil and/or reputation info
… for: allows the verifier to evaluate trust based on skin in the game, age of DID, etc
… from: network (i.e., blockchain), not controller. FOR NOW resolver has to give/find this info on its own
… but the user of a DID is who needs it, it needs to come from somewhere\

Drummond Reed: new slide

Joe Andreiu: I wanna add to Ganesh’s, possibly
… ganesh’s #2 (self-attest timestamp at creation): for: validation of temporal flow

Ganesh Annan: yes i agree, go ahead and reword it

Daniel Burnett: add joe to the C.) for future discussion

Joe Andreiu: this self-attestation, if it doesn’t line up with timeline of other relevant facts, would be helpful to raise red flags
… I want to add a new prop: “Retired Keys”
… for: key validation of keys that haven’t been revoked but have been rotated and are not the current key
… from: DID Controller (software)

Markus Sabadello:

Juan Caballero: 1 DID Created, 2 DID Updated, 3 DID Deactivated

Markus Sabadello: 1 DID Created, 2 DID Updated, 3 DID Deactivated

Markus Sabadello: 1 for: checking if a DID was available before a certain date , from: Verifiable Data registry
… 2 for: cacheing and invalidation, from: VDReg
… 3 for: checking date up until which a DID existed
… from: same VDReg

Markus Sabadello: 4 DIDDoc Version number: Similar to ChristopherA’s DID Versioning, but not from DID controller
… from: VDReg
… 5 DIDDoc CachedFlag: Whether fresh resolution or cached doc, for: trust judgments, from: Resolver

Joe Andreiu: Clarification question: Are these timestamps by def? Can we clarify which of these are/should be timestamps?

Markus Sabadello: sure, but not #5
… also, #4 should be version identifier, not necessarily number or string

Christopher Allen: yes mine as well should not be limited/assumed to be a number

Oliver Terbu: #1 resolver version

Drummond Reed: what about driver version? etc?

Oliver Terbu: #1 for security from resolver
… #1 rename resolver SPEC version
… #2 resolver METHOD CODE version from resolver for security
… #3 Resolver Engine Code Version for security from resolver

Pamela Dingle: if there’s a breach, this would be very useful for forensic analysis of whom to warn, who authenticated in a given period, etc
… so i support this

Samuel Smith: Verifiable Proof of Control Authority
… (to Manu’s clarification): I mean the root control of the DID, i.e. root control of a DID’s key

Tobias Looker: DID doc verification methods?

Samuel Smith: no, this is control of the DID, verification is a subset of that
… this is ROOT LEVEL control, other subsets of controls
… we can bikeshed the exact meaning of root control, but i’d leave it at that for now
… two formats: either the full proof or a hash and a reference to find the proof
… (to clarify regarding what kinds of proofs) - could be any kind of proof
… because it is verifiable, in aggregate it can be variable
… this must be a cryptographic proof

Tobias Looker: clarification to Justin’s property
… a party that wants to resolve a did (did client) should be able to express a did resolver option requesting a mime-type they prefer
… (justin_r says content-type, but tplooker’s property is requested content type)
… possible organization is “resolver options”

Samuel Smith: usually in a verifiable proof (eg rotation keys) also gives any keys that have been retired

Brent Zundel: should we switch to did resolution relationship?

Tobias Looker: extension to delegation property - both properties are assertions by did controller about which verification methods are authorized to invoke or delegate on behalf of the did subject
… new property: assertion - for a did controller to express verification methods authorized to assert things on behalf of the did subject
… example: which keys in the DID doc are authorized to issue VCs?
… (various concerns about wording)
… noted: nobody is happy with the name “Assertion”, needs to be solved for future

Juan Caballero: ^ (some people like assertion, some assertionProof, some issuance, some issuanceAuthority …*)

Manu Sporny: 100% agreement with Sam re: controller but then…
… new item proposed: controller - typically the entity for expressing the entity that is in control of the identifiers associated
… not the same as SamSmith’s proof (control authority), Sam’s property is keys
… manu’s point is an indirection that can lead to keys rather than being the keys
… what is at the end of the rainbow for SamSmith: answer is keys
… what is at the end of manu’s rainbow: dids
… manu believes concepts are compatible
… asking ganesh about encrypted data vaults - were there keys pulled from did doc?

Juan Caballero: (discussion to tease out compatibility– manu calls it an indirection to another DID [controller], Sam calls it an indirection to the proof of ultimate key control)

Manu Sporny: new property: key agreement key – for establishing encrypted comms

Ganesh Annan: read a definition he will annotate

Ganesh Annan: The key agreement key is used to derive a secret that is then used to

Ganesh Annan: generate a key encryption key for the receiver.

Daniel Burnett: noting all of these properties are from the did controller

Ganesh Annan: update to Markus’ did_created, updated etc
… the timestamp at which the verifiable data registry finished the CRUD operation
… drummond asks gannon to add those definitions to slides 213/214
… when the did can be resolved after the changes are made

Markus Sabadello: i agree with gannan ‘s changes

Christopher Allen: concerned that in BTCR there is a flag hidden in the value that lets the resolver know that the did is a testnet DID
… today that value is just 2 networks, should we have a field in the DID itself that says that the identifier is a test?
… also should the resolver also say that it has recognized a test?
… what if you could fool a client that isn’t fully resolving the work itself?

Joe Andrieu: suggests target network and actual network as terminology

Christopher Allen: there is a user intent that right now isn’t representative

Ganesh Annan: is this for a specific network identifier?

Christopher Allen: somebody should be able to have a sovereign plane but the client might not know that a testnet did is part of that plane

Brent Zundel: it sounds like the target verifiable data registry identifier is part of the did not the did doc? (ChristopherA agrees)
… if you ignore where it comes from, a did document that came from a testnet network looks the same, is not identifiable

Oliver Terbu: there is a column after the did in the did document where this could be notated

Joe Andrieu: if you think you’re getting back a real document from mainnet but the creator thought it was a test, that would be good to know
… 3 different areas to coordinate - in the identifier, in the did doc, and ?

Daniel Burnett: do we need all three separate pieces of information or is it the same piece of data in 3 places?

Joe Andrieu: wants it to be explicit in the did document as one piece of redundancy that can be checked
… resolver needs to know where to get it

Brent Zundel: recipient needs to know where the resolver got it

Daniel Burnett: this may simplify down to did, did doc and resolver

Christopher Allen: could we just capture one line - person who submitted and the name of the property for all people still in the queue

Oliver Terbu: btw. additional properties for capabilitiesInvocation, attestationMethod, i.e., proof purposes, was already noted in https://github.com/w3c/did-core/issues/154

Brent Zundel: apologies to those who have not been heard yet
… we would like this process to continue, google slides may not be the format moving forward
… can we move our content to a google doc for additional collaboration

Joe Andrieu: before we move anything, create a new section so that people who are in the queue can type in their proposed properties so they don’t forget
… creating additional slide 220

Brent Zundel: who will oversee the next steps here: ChristopherA volunteers

Markus Sabadello: want to ask one thing about requested content type: this is more like an input option to the resolver - is this in scope?

Brent Zundel: this is a determination to be made later

Markus Sabadello: if this is a good property I have a whole list of such things

Brent Zundel: if you are unsure at all where this goes, throw it in the doc

Joe Andrieu: there is confusion over what should go in the resolver or not - is it just a did doc before properties?

Daniel Burnett: next steps recap: get the properties into the slides, ChristopherA will pull that into a google doc and will invite people to add more

Markus Sabadello: call the title “not-yet-discussed” not self-issued properties (re slide 220)

Note: most to work in the preceding session was done by interactively adding/modifying slides on the slide deck. The results are the slides between #210 until #220, collected in a separate Google Doc. (Note added by Ivan Herman.)

6. DID Resolution

Brent Zundel: DID resolution process discussion
… goal is clarity of role of resolution, are other inputs or outputs possible, etc

Daniel Burnett: w3c process slows down combining or crossing groups, so we have to gather inputs and thoughts here but can’t promise WG charter rewrites or mergers

Markus Sabadello: i think there’s a lot of overlap between matrix parameters and DID resolution and properties relevant to both
… representations and registries also depend on resolution assumptions
… experience of VC WG lead us to this division of labor, but here
… it is harder to divide and abstract ]
… these are arguments for aligning the efforts more closely, whether that means merging or just periodic checkins or other forms of integration

Justin Richer: i see a 3part stack here
… 1: 2: resolution process that produces a DIDDoc, 3: ; resolution isnt method-specific, it is constrained by a data contract between dids and diddocs;
… i think from tech standpoint it’s essential to define that contract early on
… we’ve had a lot of problems in last few months because each of us defines resoltuion differently

Samuel Smith: +1 Justin and Markus

Ganesh Annan: +1 for defining the interfaces for resolution

Brent Zundel: +1 to resolution being a black box and that isn’t great

Justin Richer: work isn’t independent of this! this is a very normative dependency
… 1 did 2 resolution 3 did doc

Manu Sporny: i agree with markus and justin’s points
… i am opposed to officially bringing in other groups because it could really kill the feasibility of our feature freeze timeline
… we need to take those conversations into account non-normatively, and not let w3c process get in the way, but -1 for working on the spec in this group, we’re too busy as it is

Drummond Reed: i have to respectfully disagree with my fine colleague Manu because I agree with Markus and Justin that we have major discrepancies in our concept of resolution
… i am still confused by the sandwiches!
… it’s not in scope to define what resolution has to do, but actually, if spec defines valid methods, I think we DO have to define exactly what a method has to do in resolution!

Samuel Smith: i tried to resolve an ambiguity/discrepancy in the spec, and i couldn’t until spending time in the other group!

Justin Richer: +1 to Sam’s point, this is much what I wanted to add

Samuel Smith: I also disagree with Manu, it will take more time, not less, to allow DID Resolution conversation to happen in parallel!
… we should have a sandwich

Joe Andrieu: wrt W3C mess, I don’t want to comment; but wrt the cool guys samsmith and drummond … i’m with them
… the right steps in the right order reduces the time needed to do the work; extensibility conversation and resolution conversation are intimately dependent!

Justin Richer: I agree with Drummond and Joe that it will actually go faster

Juan Caballero: (process conversation)

Ivan Herman: the fact of publishing a note during the lifetime of this group reinforces our [future] request to extend lifetime/charter

Daniel Burnett: this wouldn’t be an extension, it would be a recharter with new IPR issues and need new signature
… resolution is in the [API/ transport layer] danger zone of blockers from outside
… broader question: what would make us faster? if it’s the same people doing the work, i would say keep proposing; what is it that is actually slowing down communication between groups

Manu Sporny: not a matter of if but when
… I think the same people will be doing the work if it’s pulled in, PLUS i would lose a spec editor in the process
… if someone new without a full plate took it on, that would help, but …
… isnt it just a subset of the people on that call? where’s the communication problem?
… (the same people in this WG i mean)
… as for rechartering, demonstrating success is a much better foundation for rechartering than not having accomplished original goals

Oliver Terbu: I agree with drummond that bringing resolution in is LOGICAL , although I can’t speak to the politics/process issues

Brent Zundel: from charter: “we will determine relationship between identifier and resolution process”
… so i think the contract is in scope for us

Ganesh Annan: What happens if the re-chartering process fails burn?

Daniel Burnett: If the rechartering process fails, gannan, the group does not continue beyond its original charter end date

Justin Richer: I wrote that line! this contract was exactly what i meant, which is why i am so confused that that resolution wasn’t in scope (which I assumed it was)

Markus Sabadello: I think the resolution group follows this group closely but not vice versa
… changing division of labor between documents is not my goal, i think it would be counterproductive, i just think corespec and resolutionspec need to be aligned sooner/along the way
… writing about resolution in core spec seems confusing and counterproductive

Justin Richer: one-way communication comment is accurate and i agree that it is a real problem
… it would be possible to write in a more black-box way about resolution in the core spec,
… IF we had more clarity on the inputs and outputs of that black box– particularly if there are other types of requests or other docs.

Joe Andrieu: clarifying communication and scope problem:
… Markus has already been lost to the other group, and that group will still work with same autonomy, we just need some kind of permission to talk about (and gain clarity about) their parallel work

Drummond Reed: I wanna get back to king solomon
… when I saw the line Justin added to the charter, it didnt surprise me, I always saw the sandwich
… by which i mean, i always understood resolution was a contract within scope, whether it was happening elsewhere or not

Ganesh Annan: +1

Brent Zundel: +1

Manu Sporny: -1, not clear we “have” to do the contract.

Drummond Reed: we need to clarify what will go into that other spec or spec-like appendix/thing, and be in dialogue with the people writing it

Samuel Smith: we don’t know what we’re allowed to do in the resolution; the draft spec is ambiguous on what we can do
… the user “does” resolution in parts of the spec, but we are so murky on the user’s options that writing use cases is pretty shaky and hard to do accurately!

Brent Zundel: not a new deliverable, but a PR for some kind of internal working document clarifying some of this would be within scope
… any contract (except one that bans single-method/internal resolvers) would be a helpful thing to PR and draft internally

7. Ending Stuff

Christopher Allen: The google doc to continue discussion of DID Doc/metadata/etc. Properties

Christopher Allen: BTW, I have posted my slides on “SSI: Bleeding Edges” and video