DID WG (Virtual) F2F Meeting, 2nd Day — Minutes

Date: 2020-11-03

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Amy Guy, Kristina Yasuda, Dave Longley, Wayne Chang, Drummond Reed, Eugeniu Rusu, Michael Jones, Markus Sabadello, Manu Sporny, Jonathan Holt, Shigeya Suzuki, Geunhyung Kim, Justin Richer, Joe Andrieu, Daniel Burnett, Adrian Gropper, Daniel Buchner, Kaliya Young, Juan Caballero, Orie Steele, Daniel Hardman

Regrets:

Guests: Keiko Itakura, Duy-Tung Luu, Takashi Minamii, Kazuaki Arai, Tomoaki Mizushima, Zoltan Kis, Shigeru Fujimura, Theresa O’Connor, Rossen Atanassov, Hadley Beeman

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Drummond Reed, Amy Guy

Content:

Brent Zundel: scribes today will be Drummond followed by Amy

Brent Zundel: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.p6

Brent Zundel: please go to slide 6 in the slide deck to sign up to scribe
… it is very much appreciated

Jonathan Holt: He sent an email to talk about CBOR and CDDL - is there time on the agenda for it?

Brent Zundel: Apologies. The agenda had been set for several weeks.

Jonathan Holt: Suggests looking at it in a breakout session at 1:30PM ET.

Brent Zundel: Anyone who has agenda concerns, let the chairs know.
… There’s a not a huge formal process involved.

Jonathan Holt: At IEEE, we have a vote at the start of the meeting on the agenda.

Manu Sporny: The issues have been prioritized and CBOR is a priority topic, so he expects it will be covered, especially if we can get through the abstract data model (ADM) early.

Brent Zundel: The CBOR issue will also be discussed Thursday.
… First session today: Unregistered properties and ADM
… Second session: Daniel Hardman will present on DIDComm, secure communications in production today.
… Third session: meeting with the W3C TAG
… Fourth session: Prep for horizontal review.
… the “big item” is the first session.
… first, briefly, any new introductions.

Wayne Chang: Has his own startup, co-chairs the W3C Credentials Community Group

Eugeniu Rusu: Works at Jolocom, has a DID method based on Ethereum, also working on KERI

Drummond Reed: Zoltan is from Intel working on IoT. Observing today.

1. Abstract data model

Ivan Herman: See slides

Manu Sporny: One of the big items that we need to resolve is exactly how the abstract data model will work and how we will treat unregistered properties.
… the editors and chairs have tried to formulate all the many previous meetings and discussions into a concrete set of proposals that will allow us to move forward.
… there are four proposals and 75 mins to discuss them.
… if we can successfully get through them, it will unblock progress on this topic.
… Why are we having this session: “It is now clear that the Amsterdam Face-to-Face meeting, where we decided to create the DID Spec Registries, led to a number of hand waves and miscommunications on the purpose of the registry and what it is capable of doing. There are similar issues with the Abstract Data Model.”

Michael Jones: I believe that the specification already accurately reflects the consensus from the Amsterdam F2F

Manu Sporny: So today we are going to try to identify those misunderstandings.

Markus Sabadello: This slide was the resolution from the Amsterdam F2F.
… first point: “The DID Core specification will define an abstract data model that can be cleanly represented in at least JSON, JSON-LD, and CBOR. There will also be a graphical depiction of the abstract data model. There must be lossless conversion between multiple syntaxes (modulo signatures and verification).”
… second point: “In general, the registry mechanism is the one that will be used for globally interoperable extensions.”
… third point: “The governance of the registry mechanism will be defined by the W3C DID Working Group.”
… fourth point: “Extension authors must provide references to specifications for new entries and a valid JSON-LD Context to be associated with each entry to ensure lossless conversion between serializations for both producers and consumers. This is partly being done to ensure semantic interoperability.”
… this slide is an example of the motivation for this architecture: slide
… one of the main points of discussion was “@context”.
… Some were strong supporters of JSON-LD and some were strong supports of JSON-only.
… so we decided to support both by using a abstract data model (ADM).
… and that the DID Spec Registries would be used to enable lossless conversion between representations.
… this slide shows how “translation” (lossless conversion) does not happen directly between representations, but in and out of the ADM: slide

Manu Sporny: Goals for this session
… first goal: “Come to consensus on the revised purpose of the registry now that it can be proven that it can’t do what some in the group wanted it to do (e.g., under certain scenarios, it is mathematically impossible to use it to construct certain properties like @context).”
… it is not provable that the registry cannot solve all lossless conversion tasks.
… as the registry grows, it will not be feasible to support full lossless conversion.
… second goal: “Come to consensus on whether properties are solely about the DID Subject, or if they can be about other things (e.g., the proof property).”
… the editors realized that some thought that the properties in the DID document were ALL about the DID subject, whereas others thought that some properties could describe other things. Example: the proof property.
third goal: “Come to consensus on whether preserve-by-default applies to all properties in the abstract data model.”
… fourth goal: “Come to consensus on whether implementers are allowed to “clean up” the abstract data model before an application uses it to “perform further processing higher up the stack”.”
… those are the four main goals for this session.

Manu Sporny: preserve-by-default – if a property exists in the data model, don’t delete it, don’t drop it, don’t throw an error.

Michael Jones: Clarifying question: would like to know what the registry can’t do and why?

Manu Sporny: It cannot deterministically support lossless conversion as was originally proposed.

Daniel Burnett: manu, I believe you mean that it is not possible to construct @context contents without explicitly preserving them as part of the ADM

Michael Jones: But it can still be used to get a functional @context.

Manu Sporny: we will explore that in one of the proposals.
… it has to be deterministic from a security perspective.

Michael Jones: Disagree - it just has to be well-formed and secure. To be discussed further.

Jonathan Holt: JSON-LD is not JSON. So getting to the fully functional properties of JSON-LD is the challenge.
… so @context is the “semantic sugar” used to make JSON-LD work.
… at first blush, JSON-LD and @context is much more complex that JSON.

Manu Sporny: moving now to the first goal of the session.

Daniel Burnett: I think the point is that @context adds info to the JSON. We could choose to save that extra info, but if we don’t it is not possible to create it from the remaining JSON properties plus what it is the registry

Manu Sporny: “The specification currently does not tell you how to add a new representation. This means that you have to modify DID Core to add a new representation, which will be difficult to do once DID Core is a standard.”
… so there currently is no way to add new representations.
… so: “PROPOSAL: The DID Spec Registries MUST contain a section on Representations to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify how this extensibility mechanism works as well as the requirements on representation specifications.”

Michael Jones: We can’t say “how it works”, but we can say what properties need to be preserved for any additional representations.

Justin Richer: +1 to jonathan’s point

Michael Jones: request the proposal to say, “list the invariants to be preserved” rather than say “how it works”.

Jonathan Holt: We are starting to discuss representations instead of the ADM.

Michael Jones: We should list the invariants that need to be preserved for additional representations. We should not say “how it works”.

Michael Jones: Please modify the proposal accordingly

Manu Sporny: wants to make it clear this proposal is an normative editorial decision

Wayne Chang: +1 to what self-issued said about invariants

Dave Longley: “how the extensibility mechanism works” may include “listing that certain invariants must be preserved” … and more.

Markus Sabadello: Wants to quickly agree with Manu about the need for this proposal. This is not yet the requirements.

Drummond Reed: since I wrote the section that currently has this it does have some requirements for representations but we didn’t anticipate we need to say thsi is how you add additional representations
… it’s a correction to a section
… it should be an editorial decision. I don’t disagree with mike, but we shouldn’t spend too long on this decision

Brent Zundel: Wants clarification that this is a proposal about how to add a new representation that’s not in DID Core.

Michael Jones: No, it’s not steps, it’s invariants that the new representation must preserve.

Manu Sporny: Asks Mike Jones to rewrite the proposal so it is acceptable.

Jonathan Holt: Alternate proposal: The DID Spec Registries MUST contain a section on the Abstract Data Model to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify the requirements on additional representations.

Michael Jones: Reviewing the proposed language…
… suggests one change…

Proposed resolution: The DID Spec Registries MUST contain a section on Representations to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify the requirements, such as invariants representations must preserve, on additional representations. (Manu Sporny)

Dave Longley: +1

Manu Sporny: +1

Michael Jones: +1

Brent Zundel: +1

Drummond Reed: +1

Amy Guy: +1

Ivan Herman: +1

Joe Andrieu: +1

Shigeya Suzuki: +1

Markus Sabadello: +1

Wayne Chang: +1

Eugeniu Rusu: +1

Daniel Buchner: +1

Kaliya Young: +1

Daniel Burnett: +1

Jonathan Holt: 0, we need to discuss an abstract model before representations for extensibility

Kristina Yasuda: +1

Geunhyung Kim: +1

Michael Jones: I agree with Jonathan’s point

Justin Richer: 0, this is getting a little out of order but it’s not a bad thing on its own

Adrian Gropper: +1

Resolution #1: The DID Spec Registries MUST contain a section on Representations to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify the requirements, such as invariants representations must preserve, on additional representations.

Brent Zundel: No objections, resolved

Manu Sporny: first goal accomplished, on to the second one

Michael Jones: The language on the slide does not result in actionable outcomes
Michael Jones: Therefore, we should avoid this topic entirely

Manu Sporny: second goal: “Are properties solely about the DID Subject or can they be about other things (e.g., the proof property, the unknown foo property)?”

Manu Sporny: there are multiple views on what kinds of properties can be included.
… the concrete proposal is: “PROPOSAL: A property in the Abstract Data Model can be any information expressed in the DID Document. Properties are often, but not exclusively, about the DID Subject.”
… this would make it clear that an unknown property is a property in the ADM.

Jonathan Holt: reserves his time

Michael Jones: This statement on the slide is not actionable. This is a waste of our time.

Markus Sabadello: Suggests we look at the next two slides before we run this proposal.

Manu Sporny: agrees - let’s look at the next two slides

Markus Sabadello: I am one of those people who thought that properties of the DID document were only about the DID subject.
… for example, the metadata discussion—properties about the DID document such as timestamps—were split into three buckets: properties about the DID subject, properties about the DID document, and metadata about resolution.
… properties like @context did not come up at that point.

Michael Jones: We’re not going to be able to create tests that determine whether a property is “about the DID subject” or not. Since this isn’t testable, it’s not useful to make statements about.

Markus Sabadello: this slide collects the different statements about DID document properties: slide
… all of these things suggested that DID document properties were describing the DID subject

Justin Richer: Mike: it’s testable in the property definition, not at runtime

Markus Sabadello: so when we get to discussions about property preservation, it’s important to understand what the properties describe.

Michael Jones: rhiaro If we can’t tell implementers “you can’t do that” when they’re violating the premise, it’s not useful. Because it’s not testable, we can’t determine whether implementers are doing acceptable things or not.

Markus Sabadello: this slides describes examples of “representation-specific features” that are different from Markus’ mental model of properties in the ADM: slide

Ivan Herman: It needs to be clear what the subject of a property is.

Michael Jones: You can’t know

Ivan Herman: for me, the ADM is always statements about a subject—for example an RDF subject—that we call a DID subject.

Joe Andrieu: +1 to @selfissued you can’t know

Ivan Herman: but if that’s not the case, how do you know what the property describes.

Justin Richer: Agrees. If we adopt this definition of properties, we completely throw out the semantic clarity. In that case, what’s the value of defining an ADM.
… because in that case, we have “lost the semantic subject” of all of this. We are simply “tossing around” a JSON document (or whatever representation).
… we are trying to treat all the properties as the same thing, but they are not.

Manu Sporny: There was an assertion that this proposal is not testable. But it is testable if the definition of a property is clear.

Michael Jones: I agree with preserving unknown properties. That’s independent of what properties are.

Manu Sporny: If the group is saying that we should eliminate this, then we need to go down another path that would only support registry entries.

Michael Jones: +1 @justin_r

Manu Sporny: so the danger of this path is that we’d need to remove JSON-only

Michael Jones: Saying that we might eliminate JSON is a scare tactic red herring

Manu Sporny: what would be helpful is for WG members to rewrite the proposal and put it in the IRC channel so we have some other options

Joe Andrieu: We are talking past each other. We have lots of properties in the DID document that are not strictly about the DID subject.
… thinking about the DID document as assertions about the DID subject leads us to a privacy nightmare.
… we had a similar issue with verifiable credentials - it turns out that there could be more than one.

Michael Jones: +1 to what Joe is saying

Adrian Gropper: +1 to what Joe is saying

Jonathan Holt: ok

Michael Jones: The current discussion is conflating two things that are independent.

Jonathan Holt: +1 to joe

Michael Jones: one topic is preservation of unknown properties
… a separate topic is whether a property is about the DID subject

Michael Jones: for example a Pantone rendering number - is it or is it not about the DID subject

Daniel Burnett: I also hate this “DID subject” focus.

Michael Jones: therefore we shouldn’t make statements about whether something is about the DID subject or not

Brent Zundel: +1 selfissued and burn

Adrian Gropper: I find it useful for thinking about the DID as a control structure for the DID subject.
… it may be public or private.
… if we are talking about the ADM across both contexts

Michael Jones: The statement we SHOULD be affirming as a working group is “Unknown properties MUST be preserved”

Markus Sabadello: If we are talking about preservation of unknown properties, we’ve already had a resolution about that.
… we could also expand the definition of DID document properties to say that they can describe or control interactions with the DID subject.

Justin Richer: selfissued: we can’t make that statement unless we agree what a “property” is

Proposed resolution: Unknown properties MUST be preserved (Michael Jones)

Justin Richer: selfissued: only then can we agree to that and then to what “preserved” means

Markus Sabadello: but I would still argue that representation-specific data such as @context or “YAML 1.2” are not “properties”

Dave Longley: We already have properties in the ADM that are not about the DID subject
… so a better way to address this is to talk about specific representations.

Michael Jones: Resolution 3 at an earlier topical call was: “The Working Group supports a general “preserve by default” design goal for the abstract data model. This means that a general rule for the abstract data model is to preserve properties that are not registered or documented anywhere, such as “foo”: “bar”, as long as the property name and property value datatype can be cleanly and losslessly consumed from a representation into the abstract [CUT]

Michael Jones: … This means that a general rule for the abstract data model is to preserve properties that are not registered or documented anywhere, such as “foo”: “bar”, as long as the property name and property value datatype can be cleanly and losslessly consumed from a representation into the abstract data model and produced from the abstract data model to a representation. The WG may specify exceptions to this general design goal.

Dave Longley: so we could avoid having to make statements about the ADM

Manu Sporny: we have multiple proposals that need to be run

Drummond Reed: two things… first with regard to Joe’s comment about DID subject, I must say I strongly disagree
… big difference between DIDs and VCs, DIDs are identifiers and identify a subject
… we’re clear bout that in the spec
… how they idnetify it is different in different methods but they identify a subject

Michael Jones: I propose to replace my proposal with reaffirming Resolution #3 that @rhiaro pointed us to.

Drummond Reed: second thing is: it’s important to clarify markus’.. the statements in the spec today about the properties describing the DID subject
… if that is not true, we should take the action item editorially to make sure we are clear about that in the spec

Proposed resolution: Properties of the DID Document Abstract Data Model are about or relate to the DID Subject or the DID Document’s relationship to the DID Subject. (Justin Richer)

Drummond Reed: the term property of a document is a clearly understood thing. if there are properties that are clearly not attributes of the DID subject we should be clear about that

Manu Sporny: justin_r, What do you mean by “DID Document’s relationship to the DID Subject”?

Ivan Herman: If I just look at the JSON-LD way of describing RDF, then all the current properties describe the DID subject

Manu Sporny: justin_r – does @context refer to the relationship about the DID Subject?

Ivan Herman: if we go down this path of saying that it’s not clear what the properties are about, then the RDF graph model is not clear at all.

Manu Sporny: asked about Justin’s proposal

Justin Richer: @context would NOT be an ADM property

Proposed resolution: Properties of the DID Document Abstract Data Model are about or relate to the DID Subject or the DID Document’s relationship to the DID Subject. (Manu Sporny)

Manu Sporny: -1

Markus Sabadello: +1

Justin Richer: +1

Michael Jones: -1

Orie Steele: -1

Adrian Gropper: +1

Michael Jones: This is not testable

Brent Zundel: 0

Drummond Reed: 0

Shigeya Suzuki: 0

Ivan Herman: +1 this is what the current JSON-LD definitions say

Eugeniu Rusu: 0

Justin Richer: selfissued: yes it is – in the property definitions

Dave Longley: 0

Joe Andrieu: -1

Jonathan Holt: +0.5

Ivan Herman: The resolution Mike pointed to earlier was not a formal resolution.

Markus Sabadello: Would be happy to do Mike’s proposal first.

Justin Richer: On testability of these resolutions: these will be testable in the property definition. It will be in the definition of the property itself.
… it’s not testable in runtime when you see a new property.
… which is precisely why we can’t have a definition be that loose.
… if a consumer is going to do anything about a property, it needs to know what the subject is.

Jonathan Holt: https://www.hl7.org/fhir/extensibility.html

Jonathan Holt: We struggled with this in HL7.
… we had to define many different properties. What everyone settled on was ‘try not to boil the ocean”.
… the proposal he’d like to make to resolve this is: 1) stop pretending that JSON-LD is just JSON…
… and 2) formally define the semantic relationship between the properties in the DID document that describe the DID subject.
… and also invites others to join his breakout to talk about CBOR and CDDL as a basis for the ADM
… which can help define “hardened interoperability”

Michael Jones: Since the proposal is too long, we have to do it by reference

Michael Jones: PROPOSAL https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-29-did-topic#resolution3

Proposed resolution: Unrecognized properties MUST be preserved (Michael Jones)

Michael Jones: (restated)

Manu Sporny: this resolution was already passed

Manu Sporny: +1

Michael Jones: +1

Dave Longley: +1

Amy Guy: +1

Orie Steele: ^ i thought we have that already

Drummond Reed: +1

Orie Steele: +1

Ivan Herman: +1

Joe Andrieu: +1

Markus Sabadello: +1

Shigeya Suzuki: +1

Brent Zundel: +1

Eugeniu Rusu: +1

Jonathan Holt: -1

Justin Richer: 0 🤷‍♀️

Kristina Yasuda: +1

Adrian Gropper: 0

Manu Sporny: asked Jonathan whether he would formally object

Michael Jones: I believe that it has adequate support and gives progress

Jonathan Holt: I would not formally object, however I think we should think it through more

Daniel Burnett: This proposal has come up a number of times. Jonathan has not been able to convince the group about an alternative.
… If Jonathan wants to create a different proposal, he could do that.

Michael Jones: Thank you Dan

Resolution #2: Unrecognized properties MUST be preserved.

Daniel Burnett: until we have another version, I will declare this as the consensus of the group.

Drummond Reed: The resolution passed.

Proposed resolution: If @context is present in a JSON representation, define specific constraints on its value (i.e., an array that begins with the DID core context). It does not have to be present in a JSON representation. Additionally, define plain JSON processing rules for the JSON-LD representation that reuse this same rule. (Dave Longley)

Dave Longley: This proposal relates to other ADM issues we will be discussing.

Manu Sporny: Asks about the last sentence. Can you provide an example of what that might be?

Dave Longley: If you have a JSON-LD representation of a DID document, then consumers of that representation can check to see that if @context is present and valid, then consumers can use properties in the same way they would with a JSON representation.

Markus Sabadello: Right now in the spec, there is a PR that removes all mention of @context in the JSON-only production and consumption rules.
… my feeling is that we should not talk about the features of another representation in the production rules for one representation.

Dave Longley: This is a compromise proposal.

Michael Jones: Does not understand what the first sentence of the proposal means.
… who defines the constraints in the proposal.

Dave Longley: This group defines them and puts them in the DID spec.

Michael Jones: There’s a timing issue with that. What is the future version of the spec.

Dave Longley: We treat it the same way we do now.

Ivan Herman: Would provide the same answer as Dave Longley.

Michael Jones: The statement of the proposal is ambiguously worded. It would result in different understandings by different people.

Ivan Herman: but wants to ask Dave Longley about the round-tripping. Does that get you back to the same problem—that you cannot 100% reproduce the @context if there is JSON-only processing in the middle.
or is the aim to reconstruct the @context exactly?

Brent Zundel: selfissued, is there a re-wording of it that you feel would be better?

Orie Steele: JSON only broken the data model, and what selfissued is saying is that the breakage / lack of structure is a feature… in the future, JSON only might have a JWK field, that everyone uses and the entire spec would be come irrelevant…. and YAML would just use a jwk property instead of assertionMethod / verificationMethod….

Manu Sporny: suggestion: if there are people who want to suggest a concrete change to the proposal, please suggest, otherwise let’s run the proposal

Proposed resolution: If @context is present in a JSON representation, define specific constraints on its value (i.e., an array that begins with the DID core context). It does not have to be present in a JSON representation. Additionally, define plain JSON processing rules for the JSON-LD representation that reuse this same rule. (Manu Sporny)

Manu Sporny: +1

Dave Longley: +1

Michael Jones: -1

Daniel Burnett: We need to potentially replace the Thursday issues session if needed to continue this discussion

Justin Richer: -1 this is json ld with more steps

Joe Andrieu: +1

Ivan Herman: 0 clarification is needed for this

Shigeya Suzuki: +0.5

Drummond Reed: +1

Michael Jones: It’s too ambiguous

Wayne Chang: 0

Adrian Gropper: 0

Markus Sabadello: -0.5

Orie Steele: +1

Jonathan Holt: 0, I think we need to ponder the threat models and better solutiosn

Eugeniu Rusu: 0

Michael Jones: I also agree with @justin_r’s comment

Brent Zundel: This proposal does not pass.

Jonathan Holt: +1 to Orie

Brent Zundel: so in the last 5 mins of this meeting—given that we will continue this on Thursday—what are steps that can be taken between now and then to further the chances of reaching consensus on Thursday?

Markus Sabadello: points to this slide
and suggests that we need to decide if we want to or need to preserve the representation-specific processing information shown in the slide in other representations.

Ivan Herman: +1 to markus_sabadello

Michael Jones: @context is not a property - it’s JSON-LD syntax - therefore it should not be preserved

Manu Sporny: While this conversation may have been frustrating for some, we still go through 2 out of 4 goals and partially through a third.
… suggests that folks may want to review the slides because that’s the balance of the discussion and decisions needed.
… but what Markus said is still the key question

Orie Steele: is “foo” a property?

Manu Sporny: so if folks can show up on Thursday with concrete proposals about the data model in the spec so we can arrive a unified view

Manu Sporny: yes, exactly what Markus is saying

Manu Sporny: you can’t have it both ways

Michael Jones: I believe Markus’ slide points out that @context is not a property of the ADM and thus should not be preserved.

Jonathan Holt: brent : break out zoom ?

Markus Sabadello: Agrees, but points out that “preserving all properties” conflicts with that same statement.

Brent Zundel: breakout room is on this slide: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.p3

Ivan Herman: For the discussion on Thursday, he would like to see clear examples of where the proposals on this slide goes wrong.

Brent Zundel: the breakout room is on slide 3. We will begin again at the top of the hour.

2. DID in use today

Ivan Herman: See slides

Daniel Hardman: I thought I’d talk about some fun things happening with DIDComm
… I’ll give a very high level overview of many different things rather than going deep
… for people who aren’t familiar with DIDComm, this is a mental picture of what I’m talking about
… it’s a communication method that is rooted in the security properties of DIDs
… we use the fact that a DID doc gives us keys that have an authentication method and things like that
… to construct secure comm channels
… if you want to learn more about the specifics there’s a link, you can ask lots of people in the community
… DIDComm was invented back in 2017 and the first systems that used it went into prod in late 2018
… there’s a version 2 under development at DIF
… it’s pretty similar to version 1 but a little bit of a transition in the future
… DIDComm can be used with any DID method and any transportation technology
… so the obvious one is http
… lots of stuff to say about that
… less obvious is through a file system, email, bluetooth, CHAPI, AMQP, Kafka
… a simple way to think about how it might work is you can think about s-mime secured email but instead of having security rooted in certs have it rooted in DIDs
… if you understand that comparison the mental model is right
… the format is based on the JOSE family of RFCs
… the core message itself that you send in DIDComm has an undefined or arbitrary payload
… but is structured using a JWM, this is JWT like but it’s difference is that it’s made for arbitrary messages instead of just security tokens
… there’s an ietf proposal around JWM
… when you sign it’s with JWS
… encrypt with JWE
… several different modes to use DIDComm in
… a peer to peer mode, with authenticated pairwise communication
… a little like Signal
… you could also use that with n-wise so you’re not necessarily doing one to one but could be one to five or one to nine or three to four etc
… can also do broadcast where you use a DID to sign a message and publish it to the world with a qr code, put it on a poster, send it in the mail
… and you can use it in web scenarios, client-server type of interaction that’s restful or similar
… that’s a quick overview
… for the context of tpac and the DID spec, the happy thing to say is there are lots of really cool prod systems being built on this and validate a lot of use cases for DIDs
… any questions?

Kristina Yasuda: https://tools.ietf.org/id/draft-looker-jwm-01.html

Michael Jones: what WG is JWM in?

Daniel Hardman: I don’t know, I can send a link to the RFC
… tobias submitted it, but I don’t know which group

Manu Sporny: It’s an I-D

Michael Jones: So it’s not in a working group

Justin Richer: I don’t think it’s submitted to a WG. It’s an I-D on its own. This is not RFC-track.

Manu Sporny: Not yet, no

Daniel Hardman: DIDComm takes the internal message, the JWM, and puts it in envelopes
… they are typically for encryption but can also be for signing
… by default not signed, but authenticated encryption is used
… the sender and recipient know who one another are but unless you add a signature you can’t prove the parties in the communication to a third party
… you can add the signature if you want by wrapping in a JWS envelope
… the picture shows the communication using Alice with cloud technology to Bob with mobile technology
… there’s a series of envelopes that are prepared to pass that from Alice to Bob
… those envelopes prevent those intermediaries from understanding what is happening
… they know they need to forward something to the next place in a chain
… how this chain is constructed is something you learn from the DID doc of the other party in the declaration of a service endpoint

Michael Jones: So it’s uucp ! paths ;-)

Daniel Hardman: you can also pass without having a service endpoint declared in a DID doc

Eugeniu Rusu: There’s this document as well - https://identity.foundation/didcomm-messaging/spec/

Daniel Hardman: it doesn’t require service endpoints but that’s the common way the routing information is communicated in the ecosystem
… there’s more to say about this, this is one of those things where i”m just dipping my toe in a very deep pool, trying to stay high level

Dave Longley: there’s another way to communicate where things need to go - do you have a way that allows you to use a VC to declare a service endpoint?

Daniel Hardman: you can, not described in great detail. Also use an out of band message. it would include the VC technique but basically the security around the declaration of your service endpoint, in some cases needs like VC type security in other cases it doesn’t
… you could simply transmit the data as raw data instead of signing it
… in the DIDComm community it’s called the out of band mechanism
… there’s a link about it in the Ares RFCs repos if you search for out of band or OOB
… there’s more information about it in the v2 version of the DIDComm spec
… the person that would know the most about it is Steven Curran
… The next thing is the bulk of what i want to talk about
… some interesting use cases where DIDComm is being applied
… first one is early in march, I was helping lohan [??] at DIDx doing cool stuff with low earth orbit satellites

Brent Zundel: out of band protocol: https://github.com/hyperledger/aries-rfcs/tree/master/features/0434-outofband

Daniel Hardman: he put together a system where the communication between devices on the ground in africa monitoring environmental conditions, iot devices, they need to communicate information back
… crop related or moisture related or something
… these devices communicate with a satellite over a very low bandwidth high latency connection
… they’re using peer DIDs and custom satellite oriented transport and DIDComm as the basis for secure messaging
… there’s a little excerpt of some of the code
… I thought that was an interesting one
… Most of the stuff we talk about relating to DIDs is credential oriented, but this is not a credential use cases, just a secure communication use case
… uses DIDComm for a channel that doesn’t have anything to do with http or internet
… Next one
… an interesting pilot going on with IATA
… IATA is international airline group and they’ve been concerned about the imapct of covid19 on air travel
… they’re doing a pilot for contactless proving with air travel
… this use case involves DIDComm over restful http and the did:sov method

Brent Zundel: IATA: International Air Transport Association

Daniel Hardman: there are a number of other use cases that are not DIDComm oriented doing similar things
… this is an example of the DIDComm variant of that use case that many of use are familiar with for VCs
… The next is another, currently at PoC state, Vaccify
… in Pakistan
… has built an app and a system anticipating the advent of vaccines for covid
… they are already able to apply this to the problem of other vaccines
… so it’s not just covid
… polio and some others
… the government issues a vaccine certificate to parties
… this is part of the credential community initiative
… the DIDComm use is primarily around making use of Ares RFC36/37 for issuance and proving over DIDComm
… Next is a production system, Verifiable Organizations Networks
… this is the first production system in the world that used DIDComm, it went live in late 2018
… and the use case for this system was the government of british columbia wanting to issue business licenses - liquor licenses, health inspection certificates
… so they’ve not only built and issued millions of credentials in production, they also created a public registry where these credentials could be discovered and queried
… in the context of DIDs we’ve had discussions about publicness of certain information relative to DIDs
… in this case the privacy issues don’t apply and that’s party why I thought it would be interesting
… all of the information they’re turning into credentials is publicly available anyway, it’s government information published in other forms
… DIDComm in this case was implemented in python
… lots of cool properties to that system, has been in prod for about 2 years
… Next is a bit different
… this is a product that I want to highlight, CredentialMaster
… like many of us has been focussed on making VCs easier to use
… the thing notable about them is they have built an integration with salesforce
… which gives them a global scale story that is very interesting
… the idea here is that they can leverage the capabilities of salesforce in terms of massive scale and good integration with CRM and other kinds of data management functionalities
… so they can actually track the status of credentials at scale
… if you had an institution that needed to know how many of the eight million credentials we’ve tried to issue or offered people over the last day have been accepted, how many need to be renewed, how many need to be revoked
… and do that at bulk scale, that’s the business that CredentialMaster is in
… they support multiple VC ecosystems
… many of you know I have spent my energy in the hyperledger VC ecosystem but CredentialMaster is agnostic
… hyperledger is only one of the VC types they want to ffer the world
… they also support multiple DID methods
… and use DIDComm through libraries
… making calls to DIDComm wrappers, I think javascript
… any questions?
… This is another production solution that is being used today
… at enterprise scale
… CULedger MemberPass technology
… it is a VC that is issued to somebody who is a member of a credit union
… its use case is login over DIDComm
… and DIDComm secure messaging
… unlike the pure VC use cases we tend to surface the most easily, once you’ve got a secure DIDComm channel it allows a member of support staff at a credit union to ask their credit union member a structured question and conduct interviews
… you could say I’d like to interview you for your credit worthiness and post multiple choice questions and get certified answers over DIDComm
… that’s an interesting uniqueness of that one
… The next is Anonyme labs
… they have an SDK along with this
… a different use case, it focuses on helping an individual create and manage personas in a very proactive way
… to maximise their privacy
… the screenshot highlights the fact you can created shopping persona and give yourself an arbitrary phone number in an arbitrary area code and project this persona in certain kinds of interactions
… Anonyme has integrated this with DIDComm and with native libraries for iOS so you can use DIDComm both secure messaging and credential protocols that run over DIDComm
… but they have plans for some other credentials that they want to support, or protocols they want to support
… Trustbloc is another DIDComm oriented activity
… this is an architecture diagram
… what makes this interesting is this is DIDComm using DID ion and sidetree
… it’s not using hyperledger indy at all
… it is using hyperledger fabric and Aries
… the language of implementation is Go
… most of the transport is http
… i think the universal resolver is used and some equivalence to the universal resolver that has been built in Go
… dbuc is saying they don’t use ION
… but someone gave me the impression they do
… maybe not ION but just sidetree
… that’s a fairly different technology stack
… the primary use case in this ecosystem that securekey focus is on is KYC
… but now some parts that are not from securekey and not for KYC, not sure what their use cases are
… Kiva is a cool solution i production, they have 3.5 million wallets
… that are built on top of DIDComm support
… these are for government issued national IDs in sierra leone
… primarily trying to solve economic empowerment problems there, lending money, making payments, reporting things
… they started out on hyperledger indy but originally was a sovrin kind of thing but moved away from sovrin, running their own hyperledger indy network and I believe they had plans to move to a new did:indy method
… using DIDComm mostly for VC uses
… possibly some secure messaging as well
… There’s an NHS thing going on
… There’s some research about DIDComm where the transport is the file system or email

Manu Sporny: what are you most excited about for DIDComm v2?

Daniel Buchner: We’re all DIDCommies now

Daniel Hardman: I think that having the format of the structures be JOSE opens up a lot of compatibility and use by a lot of deployed libraries

Adrian Gropper: i think of the world in terms of authorization - are there any examples or overlap with something like GNAP?

Daniel Hardman: there is bridge building between DIDComm and OIDC and SIOP stuff
… nature of that is not easy to explain in a minute

Brent Zundel: others reach out directly to daniel with questions. Thanks very much daniel

Manu Sporny: +1, thank you Daniel!

Brent Zundel: we’re anticipating Hadley Beeman and Theresa O’Connor to join us

Drummond Reed: Very nicely done, Daniel

Brent Zundel: we could talk about some of the things that were brought up in the breakout if that would be useful. We could jump back into abstract data model. Or we could jump to the comment on the request for TAG review we could address

Markus Sabadello: I’d be really interested in getting a summary from jonathan’s presentation in the breakout, I couldn’t attend

Drummond Reed: +1 to that

Manu Sporny: we could take a look at the priorty 1 issues so people can be ready with opinions on those, we pick them up when we do issue processing later in the week

Daniel Burnett: we’re not doing issue processing any more
… we can do either one now… high priority issues.. I’m not inclined to continue the discussion from earlier, I don’t think we’ll make substantial progress, better to take a break before we discuss again
… I like the idea of looking at the extra issues

Michael Jones: I agree that we reached an energetic conclusion to the Abstract Data Model conversation

Daniel Burnett: one topic is a quick review from jonathan the other is issues from editors

Brent Zundel: jonathan could you do a 5 minute review of you breakout?

Drummond Reed: +1 to 5 mins with Jonathan and then issue processing

3. Review of CDDL

Jonathan Holt: working on CDDL as a makeshift data definition of the spec. Lossless conversion of the different representation, focussing on cbor and json, but works for other s including yaml
… we spent time with json as a go to format for structured data, but what we need is a set of definitions as a specific data model
… i think cddl could serve as an in between that doesn’t replace infra but works synergistically making the ADM more concrete
… and allows for different representations
… cbor extends on json, it’s a superset, includes additional information including bytes and has an extensions mechanism built in
… and a diagnostic notation for readability
… cddl is based on ABNF rules
… cddl is a normatively defined abnf like grammar for structured data
… the logic of how it works is you have a spec with production and consumption rules, with a specific name
… define sub grammars
… constrain the set of combinations of things
… in a way that uses abnf sub grammar with naming things as text strings
… cddl is a subgrammar of abnf rules that name them and assign types
… the values can be a set of types or sequences
… but the top level production of cddl is a type
… cddl specifies a constrained set of data items
… here are all of the representations, a video I’d encourage you to check out
… these are the building blocks

Kristina Yasuda: https://www.youtube.com/watch?v=y46dARLUmmI

Jonathan Holt: the entire DID doc is in CDDL in a PR

Brent Zundel: we set aside this time to give TAG an opportunity for feedback on the DID spec, and any questions

Dmitri Zagidulin: +1 to jonathan_holt & CDDL’s usefulness in the DID spec. (maybe we can ditch the ADM, and use CDDL as the representation to define conversion rules to/from.)

Manu Sporny: dmitriz_ – I hope that was a joke – :)

Jonathan Holt: my slides regarding CDDL: https://ipfs.io/ipfs/QmX2pvFR6Ca7qQHeQn2wRUBv7LTdXAWQJf7AaJzayUZHPa/#/

Manu Sporny: because it’s not possible to do that w/o rewriting very large portions of the spec.

Manu Sporny: and throwing out abstract values spaces.

Manu Sporny: and then causing things like CBOR-LD to break

4. Greetings from the TAG

Theresa O’Connor: I don’t have anything to share offhand

Daniel Burnett: do you have any questions?

Rossen Atanassov: I’m just going to take a minute or two to get ready

Hadley Beeman: I don’t think we prepared because we thought we’d be taking questions from you but we’ll figure it out

Rossen Atanassov: issue 556 which is the design review request?

Ivan Herman: tag issue

Brent Zundel: correct

Hadley Beeman: we have let you down. We did commit to get back to you before TPAC, apologies
… the virtual tpac has put us all in a discombobulated state
… we were hoping to see security and privacy questionnaire which is a process thing but an easy thing to talk about now, where are we on that?

Brent Zundel: jonathan and wayne and adrian were working on that
… status update?

Jonathan Holt: we have a working draft, we were waiting for some feedback on some unresolved questions regarding properties that were going to be removed due to privacy concerns

Jonathan Holt: see draft

Hadley Beeman: for what it’s worth we tend to find some of the issues that they surface are ones that do prompt changes in the spec, but some end up being warnings to implementors or things better addressed at the UX or interface level
… don’t feel it’s a set of hard and fast rules, but things that should bring up additional thought about how to mitigate unintended consequences

Manu Sporny: a number of us have been in other WGs and through TAG review so we understand what to expect
… I’m wondering based on where we are if it would be helpful for us to come and present the work to the TAG
… it is going to be difficult for the TAG to extract what they need purely from the privacy and security questionnaire. It may be better done as a conversation
… not to say we meet regularly, but at least 2 or 3 touch points
… I’m afraid we’re not going to get much use out of the TAGs review
… unless the tag has assigned someone and has a list of issues, rather than lob things over a wall perhaps having a dialogue through the CR period would lead to a better use of everyone’s time

Hadley Beeman: that makes a lot of sense to me in as much as we’re the ones nominated as contacts for you
… getting a time when we can all meet is a challenge
… we’re really keen to make sure everything is documented as part of the review
… I’d be hesitant ot lean too much on face to face conversations without making sure it ends up documented in your work or in our review
… What I think would be useful for me would be to have a chat about how the spec has changed since you left the CG stage
… I think I had a godo handle on what was going on at that point but you’ve done a fair amount of work since then
… one of my intentions in wanting some additional time was to sort out that diff
… would be good for you to highlight it

Theresa O’Connor: also good to get a list of 3 or 4 of the design decisions you’ve made where you had the most contention or had interesting viable alternatives
… with a little bit of rationale about how you chose a direction
… one thing we look for is considered alternatives
… can be helpful to elucidate why your design is the way it is by showing where you could have gone but chose not to

Manu Sporny: in an attempt to address your concerns, perhaps if we could offer up some time on our regular calls? one or two or all of you could show up and we could do presentations there
… the benefit there is that it’s all transcribed and it’s not a replacement for TAG requirements, the expectation is that we still complete all the TAG questionnaires, that still happens
… but we set aside 15-30 mins over the course of 3 future calls to address exactly the items that each of you pointed out

Rossen Atanassov: is this the regular time

Manu Sporny: tuesdays at 11 eastern

Theresa O’Connor: that’s probably a decent time for rossen and me but hadley is in europe

Hadley Beeman: we can work async if need be

Jonathan Holt: hadley I appreciate your comment that this is an introspective process of documenting, supposed to stir up thoughts
… and have an opportunity for us to jot them down
… I’m wondering if you have guidance for how to go through that process more iteratively
… this is a phenomenal cutting edge technology, there’s certainly concerns about how it could be used nefariously and the challenge is we don’t know what we don’t know
… how it might be affecting privacy. we have some ideas and it’s so hard to be audited, it’s really an introspective process, do you have guidance of how to go through this?

Theresa O’Connor: the privacy interest group is the group at W3C charged with doing horizontal review of specs for privacy purposes
… the security and privacy questionnaire is a collaboration between the TAG and PING
… what we’re trying to do with it, it’s not an exhaustive document that captures every possibly concern, but a distillation of our experience doing these reviews of things that often come up
… so the start of a process is working through that document and letting it prompt your brain to think about things differently and look from a different angle
… and then once you’ve done that that iteration can happen where we can have a conversation about what you discovered during that
… and you can go to PING and ask for a privacy review from them
… their process is different from ours
… the things they look for are different and they have different backgrounds and expertise
… you might as well get reviews from both of us
… that’s where you start
… the questionnaire isn’t exhaustive, it’s just stuff we’ve noticed a lot and that we wanted to make sure people think about
… but your tech is a pretty different from a lot of the things we do reviews of, very greenfield, taking the web in a new and exciting direction
… it wouldnt surprise me if our questions aren’t really geared toward the sorts of issues you’ve had
… maybe it’s a better fit for technologies that are closer to standard web tech

Drummond Reed: True, DIDs do take the Web in a new and exciting direction.

Theresa O’Connor: this is an opportunity for us to improve the questionnaire as well
… i’d love for you think about what should we have asked
… how is this questionnaire not serving your needs or helping you reframe the possible security and privacy issues
… we want our reviews to be useful for everybody
… I’m hoping to get to the end of this review with you having made improvements to your technology and us improving the questionnaire to better address the needs of groups like yours in the future

Brent Zundel: we’ve got some good feedback from you as far as next steps
… we can reach out to you for some time during our regular meetings for more specific feedback
… anything else we could provide at this point?
… what would help you most?

Hadley Beeman: when we were last looking at this I had the things I was interested, rossen did you have others?

Rossen Atanassov: from my recollection, we did discuss in detail alternatives and what alternatives could be in the proposed explainer
… the way that you want to push DID forward
… there are a lot of good goals and there’s quite a bit of non-goals that as I was reading the explainer i had questions around
… the non-goals seem to cast umbrella of things we’re not going to worry about
… there’s a lot of technical detail and problems to solve
… we’re just starting at the stage at which we assume DIDs are ready for use
… the point is when we go down and start figuring out, you did great work already pushing your particular tech to the point where it is today, it was hard for us to piece together how you arrive at this stage, how you make these decisions
… and what were the alternatives considered along the way?
… something better but unobtainable?
… was this the only thing that came to mind?

Hadley Beeman: that fits with my memory
… thanks for having us
… we’re here to help where we can

Brent Zundel: we’re officially out of time, I was going to steal 5 or 10.. to finish the q

Adrian Gropper: governments around the world are looking for guidance on digital ID
… often mention self sovereign identity and our work in this group as an alternative
… my question to the TAG is are there other groups that we could be talking to, from a privacy perspective, in order to align with this interest?

Theresa O’Connor: in terms of privacy, there’s the PING here at w3c
… who are a number of folks interested in privacy from across the consortium
… one thing that comes to mind as far as other groups is there’s an ISO spec related to digital identity
… I’d be curious from a privacy standpoint and architectural, to hear about the relationship to that

Kristina Yasuda: there is also an ISO TR on blockchain governance

Theresa O’Connor: what are the potential interoperability concerns or opportunities to collaborate?

Kaliya Young: mDLs are a one trick pony relative to what we have

Daniel Burnett: this is something for you to know - the work was incubated before it came to the WG
… and as a result with respect to your question about alternatives
… it was interesting as we worked up the explainer, we attempted to describe the reasons why the initial developers of the incubated work did so
… I think you may be asking for a different question now
… now that it’s come into the group, what are the other decision we have discovered we need to make?
… ti would be good to understand which question you’re asking
… why was it started the way it was, vs what are things that you have since discussed and maybe chosen one direction over another?

Theresa O’Connor: the answer is both… the longer answer is incubation when successful is input into the standards process
… but it doesn’t constrain the standards process
… when incubation completes and some work is adopted by a WG that WG isn’t .. it’s hands aren’t tied by what happened during incubation
… so yes, your second point, decisions made since incubation and substantive changes that is very interesting to us
… but the first part is interesting that there may be fundamental decision taken during incubation that the WG has affirmed
… that it’s decided we were on the right track when we were doing the earlier phase of this
… this is useful as well

Daniel Burnett: we’re definitely aware that incubation is the beginning of the standards process not the end
… as chairs we explained that to the group when we started

Kristina Yasuda: @agropper https://www.iso.org/standard/76480.html this is hoped to help government adoption though this is not limited to identity

Daniel Burnett: the reason I’m bringing it up is it’s not as if we’re likely to say there was this other alternative and we might just switch to that now
… the group has affirmed many of those decision along the way
… that’s helpful to hear that those affirmation pieces are of interest

Brent Zundel: thanks, we’ll definitely be reaching out

5. Prep for horizontal review

Brent Zundel: we have had some horizontal review
… i18n and a11y groups have reviewed the spec
… their feedback was no issues?

Ivan Herman: i confirm
… they have essentially closed… I did the internationalisation one, I can’t remember who did accessibility
… i18n clearly said they are happy
… same for a11y

Brent Zundel: the feedback we’re still looking for, the TAG review has begun somewhat
… they will be helped by the security and privacy review being complete
… we’ve held off reaching out to PING and security reviewers until that questionnaire is complete
… that’s the biggest roadblock at this point
… I’m open to different possibilities for this section going forward. we could try to work through the privacy and security questionnaire concerns

Manu Sporny: +1 for getting privacy/security questionnaire done – we need that done.

Jonathan Holt: mostly about documenting and formalising a process for continuing review. Not about checkbox of having the questionnaire complete; ongoing self reflective process
… are we building the right technology
… what are the implications of that to society of how it might be implemented
… it’s an ongoing conversation

Daniel Burnett: jonathan_holt, not exactly. We must provide a doc in order to start a review

Jonathan Holt: i’ve been vocal about my concerns about security vulnerabilities
… part of my frustration is lacking that outlet to capture those thoughts
… hard for me to formulate my thoughts in a soundbite
… it would behoove us to have a continuous process of review and a way to document our questions so we make sure we have good communication about concerns and ways to mitigate them, and transparency of how this technology may be used or misused for society at large

Adrian Gropper: I don’t want to sound like I’m overstating this point but my observation is that the amount of criticism or suspicion about what’s going on in our group from people who are outside of our group
… is not slowing down
… and i find that very concerning
… i am thrilled by the number of participants we have in this work and the fact that it’s growing actively
… but i do want to point out that from my interactions in situations as broad as MyData
… there’s really just no consideration for what’s going on here
… in some cases there’s actually negative consideration or suspicion
… I think that, and talking about privacy of course, there are certain aspects of what we’re doing in getting to CR that we want to be sure we’ve at least acknowledged formally what these objections are and have documented a little bit about what the TAG was saying
… that we identify the top two or three things wrt privacy
… and document why we are making these decisions
… and I sort of feel like we keep pushing this issue to the next and next meanwhile the clock on the CR is running
… last night ultimatums about in 30 days it’ll be closed and go into a later spec
… that’s a very dangerous perspective

Manu Sporny: I’m looking at the PING tracking issue

Manu Sporny: https://github.com/w3c/did-core/issues/291

Manu Sporny: this is a requirement of w3c that we have this done
… we’ve known we need to have it done for many months

Manu Sporny: https://docs.google.com/document/d/13qLCZcks3OAb2V7GHcrSs8s9drA5OaqEPYPI1knmodc/edit#

Manu Sporny: I’m looking at the latest one, it is not done
… I hear you, jonathan, about privacy and security is continuous, I agree, and I hear adrian that it’s not particularly fun to hear we’re running out of time, but that is the reality of the situation

Daniel Burnett: The questionnaire is the entry requirement for review and discussion.

Manu Sporny: we’re supposed to submit this questionnaire to PING with plenty of time before to get review and back and forth so we’re ready to go into CR
… is the questionnaire done? we cannot proceed until it is at least done and submitted to PING

Brent Zundel: second what manu said
… I second everything jonathan and adrian yes we I want to dispel any supposition that we want to fill up the questionnaire so we can check a box and be done thinking about privacy

Manu Sporny: Yes, agreed.

Brent Zundel: I don’t believe anyone feels that way

Manu Sporny: but we have to take the first step

Manu Sporny: the first step of iterating is to take the first step

Manu Sporny: that’s filling out the document!

Brent Zundel: if we want to have an iterative process whereby we analyze and improve the privacy and security characteristics of our spec, the first step in that process is getting the questionnaire filled out and submitted so the experts at PING can do a review

Kaliya Young: i’ll raise my hand and say I can help work on the answers to these questions - perhaps Adrian and i can work on it together.

Brent Zundel: then well have feedback upon which to iterate
… I believe jonathan and adrian and wayne have done a good amount of work thus far
… the fact is that the questionnaire is still not complete and we need to know what will it take to get it done?

Drummond Reed: that was what i was going to say
… I think we made a lot of progress on some key decisions yesterday, around privacy
… I was wondering what needs to be done
… I see kaliya has volunteered to help, i’m also volunteering to help
… I want to see the proposals from yesterday incorporated into the spec as soon as possible
… I’m working on them this week
… to the extent that the volunteers working on the questionnaire can use our help, I want to understand who where when how

Jonathan Holt: there are 6 unanswered questions that we’ve posed to the group that we’re waiting for answers
… they are active areas of discussion. if we can work through those and document our thought process
… and probably add a section. i understand the need to push this, but if we have a process where we have a continuous review that would go over in spades with the rest of w3c and TAG that we’ve not only thought about it but have a process in place to continuously review this
… this is an ongoing active area of discussion

Adrian Gropper: Can someone put the 6 questions in the IRC, please?

Jonathan Holt: my frustration this morning about the resoution, the preserve by default I have reservations then, there’s no way to document those reservations and work through the security vulnerabilities. It’s a pressure to whether I’m going to formally object. We need a methodology to capture these potential vulnerabilities in order to make the spec stronger

Manu Sporny: The six questions are here

Adrian Gropper: there are two large blockers as far as I can see

Justin Richer: +1 to jonathan_holt’s points on process and moving forward

Adrian Gropper: one is the service endpoints as it relates to privacy
… we need to be clear who we expect methods to represent

Manu Sporny: and there are a entire sections at the bottom that are missing

Adrian Gropper: will there be some situations where there are counting on allow lists or deny lists of methods
… we could look at these questions fo r a few more minutes, these to me seem to be the two things we keep pushing off while working on interesting technical things and security things but not getting to the privacy issue

Brent Zundel: I’d like to see if we can answer these six questions

Ivan Herman: let’s be careful not to fall into the perfect is enemy of the good situation

Brent Zundel: +1 to ivan

Ivan Herman: it’s perfectly fine if the questionnaire is not answered and there are some open questions, but a large part is answered then send it to the relevant groups
… make it very clear we are still working
… they may have questions and we can answer and it’s not correct, etc
… we have to get the ball rolling
… because they have not been in contact with us because we have not contacted them. We will really have a problem. Contact them with what we have
… it’s not absolutely empty
… then we can work in parallel
… it will take them several weeks to schedule us as well

Daniel Burnett: this is not optional or up for discussion
… we must have the questionnaire, even if it’s imperfect
… let’s see what we can do to get those questions done
… otherwise we will never finish this spec, by the process

Brent Zundel: are we moving service discovery out of DID core? No
… manu is answering questions in the doc
… what bounds will we add to DID methods and service endpoints?
… we haven’t limited beyond no PII in DID doc, not sure if we can
… PING and TAG are not looking for a perfect spec, they just want to see we have thought about it and addressed it with guidance for implementers and mitigated as best we can
… Are web browsers assumed to be a common mode for our spec?
… No
… many instances where http isn’t involved at all
… we have some answers now, if folks would like to add comments or additional information please do so
… all those who have volunteered to get the questionnaire done, are these answers sufficient?

Manu Sporny: +1 to removing biometrics

Kaliya Young: +1

Jonathan Holt: I suggest we move biometrics from the spec and allow it as an extension or an alternate verification method

Brent Zundel: that’s best raised as an issue on DID core

Adrian Gropper: i’m willing to take these answers and go with jonathan and wayne and complete the questionnaire to the best of our ability

Kaliya Young: I’m also willing to help

Brent Zundel: please reach out to drummond and identitywoman

Ivan Herman: is there a time? deadline? when we send this to PING?

Brent Zundel: those who have volunteered is this Friday reasonable?

Jonathan Holt: between the 5 of us a time before our tuesday meeting

Kaliya Young: +1

Adrian Gropper: okay with me

Brent Zundel: by tuesday we’ll have a complete security and privacy questionnaire?

Adrian Gropper: yes, hoping kaliya and drummond are available

Drummond Reed: do we want to .. clearly out of yesterdays session we agreed to some revisions and additions to the privacy section. Do we want to complete those? do them in parallel

Brent Zundel: parallel would be just fine

Ivan Herman: +1 to brent

Brent Zundel: addressing privacy concerns is an iterative process and we will continue to do so and make things better

Manu Sporny: I’m concerned about the timeline, section 3 threat models is not filled out at all, that’s a significant amount of work
… I don’t know if folks saying yes by next tuesday understood that that is where most of the work needs to be done
… work done is good, but do not underestimate threat models

Daniel Burnett: by tuesday can this group give us a date?

Ivan Herman: knowing that contacting PING can be done when things are still open

Daniel Burnett: internal to the group, will you be able to interact between now and tuesday so at our tuesday call next we will know when to expect it?

Drummond Reed: makes sense to me

Adrian Gropper: yes

Brent Zundel: those who have volunteered to work, thank you
… no scribes for tomorrow yet..
… part of tomorrow, not for the first session
… tomorrow 10am eastern, thanks for coming

Manu Sporny: Thank you Chairs, thank you Amy!!! for scribing!!

Manu Sporny: And Markus!

7. Resolutions