01:07:44 <jeff> jeff has joined #did
01:22:55 <yoshiaki> yoshiaki has joined #did
02:01:00 <yoshiaki> yoshiaki has joined #DID
02:30:32 <yoshiaki> yoshiaki has joined #did
04:02:06 <yoshiaki> yoshiaki has joined #DID
05:29:34 <ivan> ivan has joined #did
06:02:56 <yoshiaki> yoshiaki has joined #DID
06:48:24 <yoshiaki> yoshiaki has joined #did
07:21:14 <yoshiaki_> yoshiaki_ has joined #did
07:48:38 <ivan> ivan has joined #did
08:03:51 <yoshiaki> yoshiaki has joined #DID
08:09:49 <yoshiaki_> yoshiaki_ has joined #did
10:04:58 <yoshiaki> yoshiaki has joined #DID
10:15:02 <ivan> ivan has joined #did
12:00:55 <ivan> ivan has joined #did
12:05:48 <yoshiaki> yoshiaki has joined #DID
13:45:33 <yoshiaki> yoshiaki has joined #DID
13:50:43 <ivan> ivan has joined #did
13:55:16 <tzviya> tzviya has joined #did
14:10:54 <yoshiaki_> yoshiaki_ has joined #did
15:12:07 <yoshiaki> yoshiaki has joined #DID
15:38:49 <shigeya> shigeya has joined #did
15:56:38 <Mizushima> Mizushima has joined #DID
16:18:10 <Zakim> Zakim has joined #did
16:18:17 <ivan> zakim, start meeting
16:18:17 <Zakim> RRSAgent, make logs Public
16:18:18 <Zakim> please title this meeting ("meeting: ..."), ivan
16:18:42 <ivan> Meeting: DID WG (Virtual) F2F Meeting, 2nd Day
16:18:43 <ivan> Chair: burn, brent
16:18:43 <ivan> Date: 2020-11-03
16:18:43 <ivan> Agenda: https://tinyurl.com/yydapmu3
16:18:43 <ivan> ivan has changed the topic to: Meeting Agenda 2020-11-03: https://tinyurl.com/yydapmu3
16:36:23 <burn> burn has joined #did
16:38:35 <zkis> zkis has joined #did
16:53:17 <ivan> present+
16:54:56 <tm> tm has joined #did
16:57:17 <ivan> guests+ Keiko_Itakura
16:57:43 <ivan> guests+ luu
16:59:19 <ivan> guests+ Takashi_Minamii
16:59:24 <agropper> agropper has joined #did
16:59:28 <brent> present+
16:59:37 <ivan> guests+ Kazuaki_Arai
17:00:12 <Eugeniu_Rusu_Jolocom> Eugeniu_Rusu_Jolocom has joined #did
17:00:12 <jonathan_holt> jonathan_holt has joined #did
17:00:26 <rhiaro> present+
17:00:35 <ivan> present+ kristina
17:00:39 <dlongley> present+
17:00:48 <wayne> present+
17:00:54 <kristina> kristina has joined #did
17:00:57 <drummond> drummond has joined #did
17:01:03 <kazuakiarai> kazuakiarai has joined #did
17:01:04 <drummond> present+
17:01:05 <kristina> present+
17:01:06 <selfissued> selfissued has joined #did
17:01:09 <drummond> scribe+
17:01:10 <Eugeniu_Rusu_Jolocom> present+
17:01:17 <markus_sabadello> markus_sabadello has joined #did
17:01:20 <selfissued> present+
17:01:27 <markus_sabadello> present+
17:01:33 <kazuakiarai> present+
17:01:53 <drummond> brent: scribes today will be Drummond followed by Amy
17:01:57 <brent> https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.p6
17:02:00 <manu> present+
17:02:18 <drummond> ...please go to slide 6 in the slide deck to sign up to scribe
17:02:27 <drummond> ...it is very much appreciated
17:02:32 <drummond> Amy is right!
17:02:42 <jonathan_holt> present+ jonathan_holt
17:03:14 <drummond> Note that I'm going to be on mute because it's raining so hard in Seattle that you can hear it outside my window ;-)
17:03:19 <jonathan_holt> q+
17:04:06 <manu> q+
17:04:06 <drummond> jonathan_holt: He sent an email to talk about CBOR and CDDL - is there time on the agenda for it?
17:04:11 <ivan> present+ shigeya
17:04:22 <brent> ack jonathan_holt
17:04:27 <ivan> guests+ Tomoaki_Mizushima
17:04:30 <drummond> brent: Apologies. The agenda had been set for several weeks.
17:04:52 <ivan> guests+ Zoltan_Kis
17:05:02 <Geunhyung_Kim> Geunhyung_Kim has joined #did
17:05:03 <drummond> jonathan_holt: Suggests looking at it in a breakout session at 1:30PM ET.
17:05:17 <drummond> brent: Anyone who has agenda concerns, let the chairs know.
17:05:26 <JoeAndrieu> JoeAndrieu has joined #did
17:05:27 <identitywoman> identitywoman has joined #did
17:05:30 <Geunhyung_Kim> present+ Geunhyung_Kim
17:05:31 <justin_r> justin_r has joined #did
17:05:33 <drummond> ...There's a not a huge formal process involved.
17:05:40 <manu> q?
17:05:44 <justin_r> present+
17:05:48 <brent> ack manu
17:05:50 <drummond> jonathan_holt: At IEEE, we have a vote at the start of the meeting on the agenda.
17:05:53 <JoeAndrieu> present+
17:06:05 <shigeya_> shigeya_ has joined #did
17:06:34 <drummond> manu: 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.
17:06:35 <Mizushima> Mizushima has joined #DID
17:06:50 <drummond> brent: The CBOR issue will also be discussed Thursday.
17:07:16 <drummond> ...First session today: Unregistered properties and ADM
17:07:39 <drummond> ...Second session: Daniel Hardman will present on DIDComm, secure communications in production today.
17:07:55 <drummond> ...Third session: meeting with the W3C TAG
17:08:13 <drummond> ...Fourth session: Prep for horizontal review.
17:08:27 <drummond> ...the "big item" is the first session.
17:08:32 <wayne> q+
17:08:36 <drummond> ...first, briefly, any new introductions.
17:08:43 <Eugeniu_Rusu_Jolocom> q+
17:08:50 <zkis> q+
17:08:53 <brent> ack wayne
17:09:10 <shigeya> shigeya has joined #did
17:09:21 <drummond> wayne: Has his own startup, co-chairs the W3C Credentials Community Group
17:09:29 <brent> ack Eugeniu_Rusu_Jolocom
17:09:45 <ivan> scribejs, set zkis Zoltan Kis
17:09:55 <drummond> Eugeniu_Rusu_Jolocom: Works at Jolocom, has a DID method based on Ethereum, also working on KERI
17:10:04 <brent> ack zkis
17:10:35 <drummond> Zoltan is from Intel working on IoT. Observing today.
17:10:48 <drummond> topic: Abstract data model
17:11:18 <ivan> See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.p25)
17:11:24 <drummond> manu: 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.
17:11:55 <drummond> ...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.
17:12:08 <drummond> ...there are four proposals and 75 mins to discuss them.
17:12:24 <dbuc> dbuc has joined #did
17:12:33 <drummond> ...if we can successfully get through them, it will unblock progress on this topic.
17:13:04 <drummond> ...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."
17:13:43 <selfissued> I believe that the specification already accurately reflects the consensus from the Amsterdam F2F
17:13:45 <drummond> ...So today we are going to try to identify those misunderstandings.
17:14:12 <drummond> markus_sabadello: This slide was the resolution from the Amsterdam F2F. https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_0
17:14:35 <drummond> ...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)."
17:14:53 <drummond> ...second point: "In general, the registry mechanism is the one that will be used for globally interoperable extensions."
17:15:09 <drummond> ...third point: "The governance of the registry mechanism will be defined by the W3C DID Working Group."
17:15:23 <drummond> ...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."
17:16:02 <drummond> ...this slide is an example of the motivation for this architecture: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_6
17:16:29 <drummond> ...one of the main points of discussion was "@context".
17:16:47 <drummond> ...Some were strong supporters of JSON-LD and some were strong supports of JSON-only.
17:17:03 <brent> q?
17:17:05 <drummond> ...so we decided to support both by using a abstract data model (ADM).
17:17:29 <drummond> ...and that the DID Spec Registries would be used to enable lossless conversion between representations.
17:18:25 <drummond> ...this slide shows how "translation" (lossless conversion) does not happen directly between representations, but in and out of the ADM. https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_172
17:18:44 <fujimura> fujimura has joined #did
17:18:55 <drummond> manu: Goals for this session
17:19:00 <burn> present+
17:19:10 <drummond> ...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)."
17:19:34 <fujimura> guest+ Shigeru_Fujimura
17:19:40 <drummond> ...it is not provable that the registry cannot solve all lossless conversion tasks.
17:19:59 <drummond> ...as the registry grows, it will not be feasible to support full lossless conversion.
17:20:07 <selfissued> q+
17:20:13 <jonathan_holt> q+ to discuss solution for the JSON-LD @context
17:20:16 <drummond> ...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)."
17:20:48 <agropper> present+
17:21:09 <drummond> ...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.
17:21:34 <selfissued> I need to ask a clarifying question about the assertions made in the presentation
17:21:37 <drummond> ...third goal: "Come to consensus on whether preserve-by-default applies to all properties in the abstract data model."
17:21:54 <drummond> ...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"."
17:22:16 <drummond> ...those are the four main goals for this session.
17:22:19 <ivan> q+
17:22:25 <brent> ack selfissued
17:22:30 <manu> preserve-by-default -- if a property exists in the data model, don't delete it, don't drop it, don't throw an error.
17:22:37 <yoshiaki> yoshiaki has joined #DID
17:22:38 <ivan> q-
17:22:54 <drummond> selfissued: Clarifying question: would like to know what the registry can't do and why?
17:23:20 <drummond> manu: It cannot deterministically support lossless conversion as was originally proposed.
17:23:32 <burn> manu, I believe you mean that it is not possible to construct @context contents without explicitly preserving them as part of the ADM
17:23:46 <drummond> selfissued: But it can still be used to get a functional @context.
17:24:01 <drummond> manu: we will explore that in one of the proposals.
17:24:14 <drummond> ...it has to be deterministic from a security perspective.
17:24:36 <brent> ack jonathan_holt
17:24:36 <Zakim> jonathan_holt, you wanted to discuss solution for the JSON-LD @context
17:24:42 <drummond> selfissued: Disagree - it just has to be well-formed and secure. To be discussed further.
17:25:31 <drummond> jonathan_holt: JSON-LD is not JSON. So getting to the fully functional properties of JSON-LD is the challenge.
17:25:49 <drummond> ...so @context is the "semantic sugar" used to make JSON-LD work.
17:26:11 <drummond> ...at first blush, JSON-LD and @context is much more complex that JSON.
17:26:25 <drummond> manu: moving now to the first goal of the session.
17:26:43 <burn> 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
17:26:56 <drummond> manu: "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."
17:27:21 <drummond> ...so there currently is no way to add new representations.
17:27:38 <drummond> ...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."
17:27:43 <selfissued> q+
17:27:49 <jonathan_holt> q+
17:28:03 <brent> ack selfissued
17:28:30 <drummond> selfissued: We can't say "how it works", but we can say what properties need to be preserved for any additional representations.
17:28:50 <brent> ack jonathan_holt
17:28:54 <manu> q+
17:29:05 <justin_r> +1 to jonathan's point
17:29:06 <drummond> ...request the proposal to say, "list the invariants to be preserved" rather than say "how it works".
17:29:08 <wayne> q+
17:29:16 <brent> q+ jonathan_holt
17:29:26 <drummond> jonathan_holt: We are starting to discuss representations instead of the ADM.
17:29:44 <selfissued> We should list the invariants that need to be preserved for additional representations.  We should not say "how it works".
17:29:54 <markus_sabadello> q+
17:29:55 <selfissued> Please modify the proposal accordingly
17:29:56 <drummond> manu: wants to make it clear this proposal is an normative editorial decision
17:29:57 <drummond> q+
17:29:58 <brent> ack manu
17:30:05 <brent> ack wayne
17:30:21 <drummond> wayne: +1 to what self-issued said about invariants
17:30:22 <dlongley> "how the extensibility mechanism works" may include "listing that certain invariants must be preserved" ... and more.
17:30:34 <brent> ack markus_sabadello
17:31:08 <drummond> markus_sabadello: Wants to quickly agree with Manu about the need for this proposal. This is not yet the requirements.
17:31:11 <brent> ack drummond
17:31:17 <rhiaro> scribe+
17:31:38 <rhiaro> drummond: 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
17:31:40 <brent> q+ to ask a clarifying question
17:31:42 <rhiaro> ... it's a correction to a section
17:31:55 <brent> ack brent
17:31:55 <Zakim> brent, you wanted to ask a clarifying question
17:31:56 <rhiaro> ... it should be an editorial decision. I don't disagree with mike, but we shouldn't spend too long on this decision
17:32:19 <selfissued> q+
17:32:26 <brent> ack selfissued
17:32:27 <manu> q+ to take up the proposal
17:32:27 <drummond> brent: Wants clarification that this is a proposal about how to add a new representation that's not in DID Core.
17:32:54 <selfissued> No, it's not steps - it's invariants that the new representation must preserve
17:32:59 <drummond> selfissued: No, it's not steps, it's invariants that the new representation must preserve.
17:33:30 <drummond> manu: Asks Mike Jones to rewrite the proposal so it is acceptable.
17:33:52 <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 representation specifications.
17:33:58 <drummond> selfissued: Reviewing the proposed language...
17:34:09 <drummond> ...suggests one change...
17:34:13 <selfissued> s/representation specifications/additional representations/
17:34:31 <manu> 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 the requirements, such as invariants representations must preserve, on additional representations.
17:34:34 <dlongley> +1
17:34:35 <manu> +1
17:34:37 <selfissued> +1
17:34:38 <brent> +1
17:34:38 <drummond> +1
17:34:39 <rhiaro> +1
17:34:41 <ivan> +1
17:34:41 <JoeAndrieu> +1
17:34:42 <shigeya> +1
17:34:43 <markus_sabadello> +1
17:34:44 <wayne> +1
17:34:44 <Eugeniu_Rusu_Jolocom> +1
17:34:49 <dbuc> +1
17:34:50 <identitywoman> +1
17:34:53 <burn> +1
17:35:01 <jonathan_holt> 0, we need to discuss an abstract model before representations for extensibility
17:35:12 <kristina> +1
17:35:14 <Geunhyung_Kim> +1
17:35:15 <selfissued> I agree with Jonathan's point
17:35:18 <ivan> present+ dbuc
17:35:18 <ivan> present+ identitywoman
17:35:25 <justin_r> 0, this is getting a little out of order but it's not a bad thing on its own
17:35:28 <agropper> +1
17:35:47 <manu> RESOLVED: 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.
17:35:55 <drummond> brent: No objections, resolved
17:36:11 <drummond> manu: first goal accomplished, on to the second one
17:36:33 <selfissued> The language on the slide does not result in actionable outcomes
17:36:35 <drummond> ...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)?"
17:36:44 <selfissued> Therefore, we should avoid this topic entirely
17:36:47 <selfissued> q+
17:37:00 <drummond> ...there are multiple views on what kinds of properties can be included.
17:37:28 <drummond> ...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."
17:37:50 <markus_sabadello> q+
17:37:50 <ivan> q+
17:37:51 <drummond> ...this would make it clear that an unknown property is a property in the ADM.
17:38:06 <brent> ack manu
17:38:06 <Zakim> manu, you wanted to take up the proposal
17:38:10 <drummond> jonathan_holt: reserves his time
17:38:22 <brent> ack selfissued
17:38:52 <drummond> selfissued: This statement on the slide is not actionable. This is a waste of our time.
17:38:52 <justin_r> q+
17:38:54 <manu> q+ to demonstrate how it is directly testable
17:38:55 <brent> ack markus_sabadello
17:39:19 <drummond> markus_sabadello: Suggests we look at the next two slides before we run this proposal.
17:39:33 <drummond> manu: agrees - let's look at the next two slides
17:40:11 <JoeAndrieu> q+ to say that from an RDF standpoint, we have tons of properties about subjects other than the DID Subject
17:40:17 <drummond> markus_sabadello: I am one of those people who thought that properties of the DID document were only about the DID subject.
17:41:20 <drummond> ...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.
17:41:31 <drummond> ...properties like @context did not come up at that point.
17:41:54 <selfissued> 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.
17:42:13 <drummond> ...this slide collects the different statements about DID document properties: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_52
17:42:54 <drummond> ...all of these things suggested that DID document properties were describing the DID subject
17:43:15 <justin_r> selfissued: it's testable in the property definition, not at runtime
17:43:24 <drummond> ...so when we get to discussions about property preservation, it's important to understand what the properties describe.
17:43:54 <selfissued> 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.
17:44:22 <drummond> ...this slides describes examples of "representation-specific features" that are different from Markus' mental model of properties in the ADM: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_58
17:44:34 <brent> q?
17:44:41 <selfissued> q+
17:44:56 <brent> ack ivan
17:45:52 <drummond> ivan: It needs to be clear what the subject of a property is.
17:46:25 <selfissued> You can't know
17:46:33 <drummond> ...for me, the ADM is always statements about a subject—for example an RDF subject—that we call a DID subject.
17:46:39 <brent> ack justin_r
17:46:42 <JoeAndrieu> +1 to @selfissued you can't know
17:46:43 <agropper> q+
17:46:47 <drummond> ...but if that's not the case, how do you know what the property describes.
17:47:21 <by_caballero___juan> by_caballero___juan has joined #did
17:47:22 <drummond> justin_r: 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.
17:47:26 <by_caballero___juan> present+
17:48:07 <drummond> ...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).
17:48:10 <brent> ack manu
17:48:10 <Zakim> manu, you wanted to demonstrate how it is directly testable
17:48:20 <drummond> ...we are trying to treat all the properties as the same thing, but they are not.
17:48:58 <drummond> manu: There was an assertion that this proposal is not testable. But it is testable if the definition of a property is clear.
17:49:04 <selfissued> I agree with preserving unknown properties.  That's independent of what properties are.
17:49:21 <markus_sabadello> q+
17:49:36 <dlongley> q+ to say i think this is coming from trying to find a solution to a problem where we don't have rules for how to handle `@context` when it appears in JSON ... and if we have "JSON-only processing rules" for both the JSON and JSON-LD representations for `@context`, we solve this problem another way
17:49:39 <drummond> ...If the group is saying that we should eliminate this, then we need to go down another path that would only support registry entries.
17:49:40 <selfissued> +1 @justin_r
17:49:53 <drummond> ...so the danger of this path is that we'd need to remove JSON-only
17:50:07 <selfissued> Saying that we might eliminate JSON is a scare tactic red herring
17:50:15 <brent> ack JoeAndrieu
17:50:15 <Zakim> JoeAndrieu, you wanted to say that from an RDF standpoint, we have tons of properties about subjects other than the DID Subject
17:50:21 <drummond> ...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
17:50:39 <manu> q+ to run Justin's proposal.
17:50:59 <selfissued> +1 to what Joe is saying
17:51:02 <drummond> JoeAndrieu: We are talking past each other. We have lots of properties in the DID document that are not strictly about the DID subject.
17:51:20 <drummond> ...thinking about the DID document as assertions about the DID subject leads us to a privacy nightmare.
17:51:51 <drummond> ...we had a similar issue with verifiable credentials - it turns out that there could be more than one.
17:51:53 <agropper> +1 to what Joe is saying
17:52:03 <drummond> q+ to talk about DID subject and why this is not VCs
17:52:04 <jonathan_holt> ok
17:52:10 <brent> ack jonathan_holt
17:52:12 <brent> ack selfissued
17:52:34 <drummond> selfissued: The current discussion is conflating two things that are independent.
17:52:53 <jonathan_holt> +1 to joe
17:52:56 <drummond> ...one topic is preservation of unknown properties
17:53:16 <drummond> ...a separate topic is whether a property is about the DID subject
17:53:21 <brent> q
17:53:39 <drummond> ...for example a Pantone rendering number - is it or is it not about the DID subject
17:53:50 <brent> ack agropper
17:53:51 <burn> I also hate this "DID subject" focus.
17:53:54 <drummond> ...therefore we shouldn't make statements about whether something is about the DID subject or not
17:54:04 <brent> +1 selfissued and burn
17:54:26 <drummond> agropper: I find it useful for thinking about the DID as a control structure for the DID subject.
17:54:34 <drummond> ...it may be public or private.
17:54:47 <brent> ack markus_sabadello
17:54:51 <drummond> ...if we are talking about the ADM across both contexts
17:54:51 <selfissued> The statement we SHOULD be affirming as a working group is "Unknown properties MUST be preserved"
17:54:52 <Orie> Orie has joined #did
17:55:00 <Orie> present+
17:55:19 <drummond> markus_sabadello: If we are talking about preservation of unknown properties, we've already had a resolution about that.
17:55:49 <drummond> ...we could also expand the definition of DID document properties to say that they can describe or control interactions with the DID subject.
17:55:52 <justin_r> selfissued: we can't make that statement unless we agree what a "property" is
17:55:53 <selfissued> PROPOSAL: Unknown properties MUST be preserved
17:56:19 <justin_r> selfissued: only then can we agree to that and then to what "preserved" means
17:56:19 <brent> ack dlongley
17:56:19 <Zakim> dlongley, you wanted to say i think this is coming from trying to find a solution to a problem where we don't have rules for how to handle `@context` when it appears in JSON ...
17:56:22 <Zakim> ... and if we have "JSON-only processing rules" for both the JSON and JSON-LD representations for `@context`, we solve this problem another way
17:56:29 <drummond> ...but I would still argue that representation-specific data such as @context or "YAML 1.2" are not "properties"
17:56:54 <drummond> dlongley: We already have properties in the ADM that are not about the DID subject
17:57:15 <drummond> ...so a better way to address this is to talk about specific representations.
17:57:31 <selfissued> Thanks @rhiaro.  Resolution 3 there 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]
17:57:50 <brent> ack manu
17:57:50 <Zakim> manu, you wanted to run Justin's proposal.
17:57:55 <drummond> ...so we could avoid having to make statements about the ADM
17:58:04 <ivan> q?
17:58:14 <drummond> manu: we have multiple proposals that need to be run
17:58:17 <selfissued> ... 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.
17:58:24 <brent> ack drummond
17:58:24 <Zakim> drummond, you wanted to talk about DID subject and why this is not VCs
17:58:30 <rhiaro> drummond: two things... first with regard to Joe's comment about DID subject, I must say I strongly disagree
17:58:40 <rhiaro> ... big difference between DIDs and VCs, DIDs are identifiers and identify a subject
17:58:43 <rhiaro> ... we're clear bout that in the spec
17:58:52 <rhiaro> ... how they idnetify it is different in different methods but they identify a subject
17:59:09 <selfissued> I propose to replace my proposal with reaffirming Resolution #3 that @rhiaro pointed us to.
17:59:13 <rhiaro> ... second thing is: it's important to clarify markus'.. the statements in the spec today about the properties describing the DID subject
17:59:23 <ivan> q+
17:59:26 <rhiaro> ... if that is not true, we should take the action item editorially to make sure we are clear about that in the spec
17:59:34 <justin_r> PROPOSAL: 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.
17:59:45 <rhiaro> ... 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
18:00:02 <brent> ack ivan
18:00:07 <manu> q+ to ask for clarification on justin_r's proposal.
18:00:30 <manu> justin_r, What do you mean by "DID Document's relationship to the DID Subject"?
18:00:46 <drummond> ivan: If I just look at the JSON-LD way of describing RDF, then all the current properties describe the DID subject
18:00:47 <manu> justin_r -- does @context refer to the relationship about the DID Subject?
18:00:49 <brent> ack manu
18:00:49 <Zakim> manu, you wanted to ask for clarification on justin_r's proposal.
18:01:23 <drummond> ...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.
18:01:31 <markus_sabadello> q+
18:01:41 <drummond> manu: asked about Justin's proposal
18:02:06 <drummond> justin_r: @context would NOT be an ADM property
18:02:07 <brent> ack markus_sabadello
18:02:13 <brent> q+ markus_sabadello
18:02:15 <manu> PROPOSAL: 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.
18:02:19 <manu> -1
18:02:21 <markus_sabadello> +1
18:02:22 <justin_r> +1
18:02:23 <selfissued> -1
18:02:24 <Orie> -1
18:02:24 <agropper> +1
18:02:30 <selfissued> This is not testable
18:02:31 <brent> 0
18:02:31 <drummond> 0
18:02:33 <shigeya> 0
18:02:35 <ivan> +1 this is what the current JSON-LD definitions say
18:02:41 <Eugeniu_Rusu_Jolocom> 0
18:02:41 <justin_r> selfissued: yes it is -- in the property definitions
18:02:43 <dlongley> 0
18:02:45 <justin_r> q+ to talk about testing
18:02:51 <JoeAndrieu> -1
18:02:54 <jonathan_holt> +0.5
18:04:47 <brent> q?
18:04:48 <jonathan_holt> q+, to discuss solution, but defer to justin_r first
18:04:48 <drummond> ivan: The resolution he pointed to earlier was not a formal resolution.
18:04:58 <jonathan_holt> q+
18:05:02 <brent> ack justin_r
18:05:02 <Zakim> justin_r, you wanted to talk about testing
18:05:05 <drummond> markus_sabadello: Would be happy to do Mike's proposal first.
18:05:38 <drummond> justin_r: On testability of these resolutions: these will be testable in the property definition. It will be in the definition of the property itself.
18:05:53 <drummond> ...it's not testable in runtime when you see a new property.
18:06:17 <drummond> ...which is precisely why we can't have a definition be that loose.
18:06:42 <brent> ack jonathan_holt
18:06:46 <drummond> ...if a consumer is going to do anything about a property, it needs to know what the subject is.
18:06:49 <jonathan_holt> https://www.hl7.org/fhir/extensibility.html
18:06:58 <drummond> jonathan_holt: We struggled with this in HL7.
18:07:37 <drummond> ...we had to define many different properties. What everyone settled on was 'try not to boil the ocean".
18:08:12 <drummond> ...the proposal he'd like to make to resolve this is: 1) stop pretending that JSON-LD is just JSON...
18:08:54 <drummond> ...and 2) formally define the semantic relationship between the properties in the DID document that describe the DID subject.
18:09:22 <drummond> ...and also invites others to join his breakout to talk about CBOR and CDDL as a basis for the ADM
18:09:38 <manu> q?
18:09:46 <drummond> ...which can help define "hardened interoperability"
18:09:48 <selfissued> Since the proposal is too long, we have to do it by reference
18:09:52 <selfissued> PROPOSAL https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-29-did-topic#resolution3
18:10:44 <selfissued> PROPOSAL: "Unrecognized properties MUST be preserved"
18:10:47 <selfissued> (restated)
18:10:54 <drummond> manu: this resolution was already passed
18:10:56 <manu> +1
18:10:59 <selfissued> +1
18:11:00 <dlongley> +1
18:11:00 <rhiaro> +1
18:11:00 <Orie> ^ i thought we have that already
18:11:00 <drummond> +1
18:11:01 <Orie> +1
18:11:03 <JoeAndrieu> +1
18:11:05 <markus_sabadello> +1
18:11:05 <shigeya> +1
18:11:05 <brent> +1
18:11:07 <Eugeniu_Rusu_Jolocom> +1
18:11:07 <jonathan_holt> -1
18:11:08 <justin_r> 0 🤷‍♀️
18:11:18 <ivan> +1
18:11:20 <kristina> +1
18:11:25 <agropper> 0
18:11:35 <yoshiaki> yoshiaki has joined #did
18:12:49 <drummond> manu: asked Jonathan whether he would formally object
18:12:55 <selfissued> I believe that it has adequate support and gives progress
18:13:09 <drummond> jonathan_holt: I would not formally object, however I think we should think it through more
18:13:54 <zkis2> zkis2 has joined #did
18:13:56 <drummond> burn: This proposal has come up a number of times. Jonathan has not been able to convince the group about an alternative.
18:14:35 <drummond> ...If Jonathan wants to create a different proposal, he could do that.
18:15:02 <selfissued> Thank you Dan
18:15:16 <manu> RESOLVED: Unrecognized properties MUST be preserved.
18:15:32 <drummond> ...until we have another version, I will declare this as the consensus of the group.
18:15:38 <brent> q?
18:15:41 <drummond> The resolution passed.
18:15:59 <dlongley> PROPOSAL: 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.
18:16:12 <drummond> dlongley: This proposal relates to other ADM issues we will be discussing.
18:16:46 <manu> q+ to ask for clarificatin
18:16:52 <brent> ack manu
18:16:52 <Zakim> manu, you wanted to ask for clarificatin
18:17:02 <selfissued> q+ to ask for clarification
18:17:13 <drummond> manu: Asks about the last sentence. Can you provide an example of what that might be?
18:17:28 <markus_sabadello> q+ I'd like to comment on this too
18:17:57 <brent> ack markus_sabadello
18:18:05 <drummond> dlongley: 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-LD representation.
18:18:18 <dlongley> s/with a JSON-LD/with a JSON/
18:18:42 <drummond> 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.
18:19:08 <drummond> ...my feeling is that we should not talk about the features of another representation in the production rules for one representation.
18:19:18 <ivan> q+
18:19:20 <brent> ack selfissued
18:19:20 <Zakim> selfissued, you wanted to ask for clarification
18:19:20 <drummond> dlongley: This is a compromise proposal.
18:19:21 <manu> q+ to run the proposal
18:19:36 <drummond> selfissued: Does not understand what the first sentence of the proposal means.
18:19:39 <markus_sabadello> q+
18:19:46 <drummond> ...who defines the constraints in the proposal.
18:20:06 <drummond> dlongley: This group defines them and puts them in the DID spec.
18:20:39 <drummond> selfissued: There's a timing issue with that. What is the future version of the spec.
18:20:48 <brent> ack ivan
18:20:49 <drummond> dlongley: We treat it the same way we do now.
18:21:00 <jonathan_holt> q+ to state my security concerns
18:21:07 <drummond> ivan: Would provide the same answer as Dave Longley.
18:21:26 <dlongley> q+ to answer ivan
18:21:30 <brent> q+ to ask about use cases driving these proposals
18:21:33 <selfissued> The statement of the proposal is ambiguously worded.  It would result in different understandings by different people.
18:21:53 <drummond> ...but wants to ask Dave Longley abou 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.
18:21:57 <brent> selfissued, is there a re-wording of it that you feel would be better?
18:22:16 <Orie> 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....
18:22:17 <drummond> ...or is the aim to reconstruct the @context exactly?
18:22:24 <brent> ack manu
18:22:24 <Zakim> manu, you wanted to run the proposal
18:22:54 <drummond> manu: suggestion: if there are people who want to suggest a concrete change to the proposal, please suggest, otherwise let's run the proposal
18:23:27 <manu> PROPOSAL: 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.
18:23:27 <manu> +1
18:23:33 <dlongley> +1
18:23:38 <selfissued> -1
18:23:39 <drummond> burn: We need to potentially replace the Thursday issues session if needed to continue this discussion
18:23:40 <justin_r> -1 this is json ld with more steps
18:23:40 <JoeAndrieu> +1
18:23:49 <ivan> 0 clarification is needed for this
18:23:50 <shigeya> +0.5
18:23:51 <drummond> +1
18:23:53 <selfissued> It's too ambiguous
18:23:57 <wayne> 0
18:24:00 <agropper>  0
18:24:01 <markus_sabadello> -0.5
18:24:10 <Orie> +1
18:24:17 <jonathan_holt> 0, I think we need to ponder the threat models and better solutiosn
18:24:18 <Eugeniu_Rusu_Jolocom> 0
18:24:19 <selfissued> I also agree with @justin_r's comment
18:24:41 <drummond> brent: This proposal does not pass.
18:25:01 <manu> q+
18:25:04 <dlongley> q-
18:25:09 <jonathan_holt> +1 to Orie
18:25:23 <brent> q-
18:25:28 <drummond> ...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?
18:25:43 <brent> ack markus_sabadello
18:26:15 <drummond> markus_sabadello: points to this slide: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.ga6b14e98d2_1_58
18:26:15 <ivan> +1 to markus_sabadello
18:27:00 <selfissued> q+
18:27:00 <brent> ack jonathan_holt
18:27:01 <Zakim> jonathan_holt, you wanted to state my security concerns
18:27:03 <drummond> ...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.
18:27:12 <manu> q?
18:27:26 <jonathan_holt> q-
18:27:32 <brent> ack manu
18:27:34 <selfissued> `@context` is not a property - it's JSON-LD syntax - therefore it should not be preserved
18:28:07 <drummond> manu: While this conversation may have been frustrating for some, we still go through 2 out of 4 goals and partially through a third.
18:28:38 <drummond> ...suggests that folks may want to review the slides because that's the balance of the discussion and decisions needed.
18:28:58 <drummond> ...but what Markus said is still the key question
18:29:10 <brent> ack selfissued
18:29:24 <markus_sabadello> q+
18:29:32 <Orie> is "foo" a property?
18:29:37 <drummond> ...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
18:29:41 <brent> ack markus_sabadello
18:30:07 <ivan> q+
18:30:09 <manu> yes, exacrtly what Markus is saying
18:30:12 <manu> you can't have it both ways
18:30:15 <drummond> selfissued: I believe Markus' slide points out that @context is not a property of the ADM and thus should not be preserved.
18:30:30 <jonathan_holt> brent :  break out zoom ?
18:30:38 <drummond> markus_sabadello: Agrees, but points out that "preserving all properties" conflicts with that same statement.
18:30:58 <brent> breakout room is on this slide: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit?pli=1#slide=id.p3
18:31:13 <drummond> ivan: For the discussion on Thursday, he would like to see clear examples of where the proposals on this slide goes wrong.
18:31:35 <drummond> brent: the breakout room is on slide 3. We will begin again at the top of the hour.
18:31:57 <dbuc> Well that was fun - who needs a 10:30am cocktail?
18:31:59 <burn> +1 to staying here
18:32:35 <dbuc> Any time my man(u)
18:33:05 <kristina> @ shigeya me too
18:39:26 <zkis3> zkis3 has joined #did
18:54:58 <selfissued> q+
19:00:35 <manu> ack ivan
19:00:45 <brent> ack selfissued
19:01:42 <ivan> Topic: DID in use today
19:02:09 <ivan> See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_20)
19:02:24 <ivan> present+ danielhardman
19:03:07 <brent> q?
19:03:21 <manu> present+
19:03:30 <rhiaro> daniel: I thought I'd talk about some fun things happening with DIDComm
19:03:38 <rhiaro> ... I'll give a very high level overview of many different things rather than going deep
19:04:00 <rhiaro> ... for people who aren't familiar with DIDComm, this is a mental picture of what I'm talking about
19:04:08 <rhiaro> ... it's a communication method that is rooted in the security properties of DIDs
19:04:18 <rhiaro> ... we use the fact that a DID doc gives us keys that  have an authentication method and things like that
19:04:24 <rhiaro> ... to construct secure comm channels
19:04:35 <rhiaro> ... if you want to learn mor eabout the specifics there's a link, you can ask lots of people in the community
19:04:48 <rhiaro> ... DIDComm was invented back in 2017 and the first systems that used it went into prod in late 2018
19:04:53 <rhiaro> ... there's a version 2 under development at DIF
19:05:02 <rhiaro> ... it's pretty similar to version 1 but a little bit of a transition in the future
19:05:10 <rhiaro> ... DIDComm can be used with any DID method and any transportation technology
19:05:13 <rhiaro> ... so the obvious one is http
19:05:16 <rhiaro> ... lots of stuff to say about that
19:05:33 <rhiaro> ... less obvious is through a file system, email, bluetooth, CHAPI, AMQP, Kafka
19:06:02 <rhiaro> ... a simple way to think about how it might work is you can think about smime secured email but instead of having security rooted in certs have it rooted in DIDs
19:06:13 <rhiaro> ... if you understand that comparison the mental model is irght
19:06:20 <rhiaro> ... the format is based on the JOSE family of RFCs
19:06:32 <rhiaro> ... the core message itself that you send in DIDComm has an undefined or arbitrary payload
19:06:50 <rhiaro> ... but is structured using a JWM, this is JWT like but it's difference is that it's made for abitrary messages instaed of just security tokens
19:06:55 <rhiaro> ... there's an ietf proposal around JWM
19:06:57 <rhiaro> ... when you sign it's with JWS
19:07:00 <rhiaro> ... encrypt with JWE
19:07:07 <rhiaro> ... several different modes to use DIDComm in
19:07:15 <rhiaro> ... a peer to peer mode, with authenticated pairwise communication
19:07:17 <rhiaro> ... a little like Signal
19:07:32 <rhiaro> ... 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
19:07:46 <rhiaro> ... can also do broadcast where you use a DID to sign a messag ean dpublish it to the world with a qr code, put it on a poster, send it in the mail
19:07:56 <rhiaro> ... and you can use it in web scenarios, client-server type of interaction that's restful or similar
19:07:58 <rhiaro> ... that's a quick overview
19:08:14 <rhiaro> ... 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
19:08:22 <rhiaro> ... any questions?
19:08:41 <rhiaro> selfissued: what WG is JWM in?
19:08:46 <kristina> https://tools.ietf.org/id/draft-looker-jwm-01.html
19:08:48 <rhiaro> daniel: I don't know, I can send a link to the RFC
19:08:56 <rhiaro> ... tobias submitted it, but I don't know which group
19:09:07 <manu> It's an I-D
19:09:16 <selfissued> So it's not in a working group
19:09:25 <justin_r> I don't think it's submitted to a WG. It's an I-D on its own. This is not RFC-track.
19:09:28 <manu> Not yet, no
19:09:30 <rhiaro> daniel: DIDComm takes the internal message, the JWM, and puts it in envelopes
19:09:37 <rhiaro> ... they are typically for encryption but can also be for signing
19:09:44 <rhiaro> ... by default not signed, but authenticated encryption is used
19:09:59 <rhiaro> ... 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
19:10:06 <rhiaro> ... you can add the signature if you want by wrapping ina  JWS envelope
19:10:17 <rhiaro> ... the picture shows the communication usin gAlice with cloud technology to Bob with mobile technology
19:10:26 <rhiaro> ... there's a series of envelopes that are prepared to pass that from Alice to Bob
19:10:37 <rhiaro> ... those envelopes prevent those intimediatries from understanding what is happening
19:10:43 <rhiaro> ... they know they need to forward something to the next place in a chain
19:10:55 <rhiaro> ... how this chain is constructed is something you learn from the DID doc of the other party in the declaration of a service endpoint
19:10:59 <selfissued> So it's uucp ! paths ;-)
19:11:02 <rhiaro> ... you can also pass without having a service endpoint declared in a DID doc
19:11:05 <Eugeniu_Rusu_Jolocom> There's this document as well - https://identity.foundation/didcomm-messaging/spec/
19:11:16 <rhiaro> ... it doens't require service endpoints but that's the common way the routing information is communicated in the ecosystem
19:11:21 <brent> q?
19:11:28 <rhiaro> ... there's mor eto 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
19:11:28 <dlongley> q+
19:11:40 <brent> ack dlongley
19:11:54 <rhiaro> dlongley: there's another way to communicate wher ethings need to go - do you have a way that allows you to use a VC to declare aservice endpoint?
19:12:21 <rhiaro> daniel: 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
19:12:28 <rhiaro> ... you could simply transmit the data as raw data instead of signing it
19:12:38 <rhiaro> ... in the DIDComm community it's called the outof band mechanism
19:12:54 <rhiaro> ... there's a link about it in the Ares RFCs repos if you search for out of band or OOB
19:13:02 <rhiaro> ... there's more information about it in the v2 version of the DIDComm spec
19:13:07 <rhiaro> ... the person that would kno wthe most about it is Steven Curran
19:13:27 <ivan> scribejs, set daniel Daniel Hardman
19:13:31 <rhiaro> ... The next thing is the bulk of what i want to talk about
19:13:38 <rhiaro> ... some interesting use cases where DIDComm is being applied
19:14:02 <rhiaro> ... first one is early in march, I was helping lohan [??] at DIDx doing cool stuff with low earth orbit satellites
19:14:05 <brent> out of band protocol: https://github.com/hyperledger/aries-rfcs/tree/master/features/0434-outofband
19:14:22 <rhiaro> ... 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
19:14:27 <rhiaro> ... crop related or moisture related or something
19:14:36 <rhiaro> ... these devices communicate with a satelltie over a very low bandwidth high latency connection
19:14:48 <rhiaro> ... they're using peer DIDs and custom satellite oriented transport and DIDComm as the basis for secure messaging
19:14:56 <rhiaro> ... there's a little excerpt of some of the code
19:15:15 <rhiaro> ... I thought that was an itneresting one
19:15:28 <rhiaro> ... 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
19:15:36 <rhiaro> ... uses DIDComm for a channel that doesn't have anything to do with http or internet
19:15:45 <rhiaro> ... Next one
19:15:50 <rhiaro> ... an interesting pilot going on with IATA
19:16:15 <rhiaro> ... IATA is international airline group and they've been concerned about th eimapct of covid19 on airtravel
19:16:23 <rhiaro> ... they're doing a pilot for contactless proving with air travel
19:16:31 <rhiaro> ... this use case involves DIDComm over restful http and the did:sov method
19:16:33 <brent> IATA:  International Air Transport Association
19:16:40 <rhiaro> ... there are a number of other use cases that are not DIDComm oriented doing similar things
19:16:51 <rhiaro> ... this is an example of the DIDComm varient of that use case that many of use are familiar with for VCs
19:17:02 <rhiaro> ... The next is another, currently at PoC state, Vaccify
19:17:05 <rhiaro> ... in Pakistan
19:17:15 <rhiaro> ... has built an app and a system anticipating the advent of vaccines for covid
19:17:22 <rhiaro> ... they are already able to apply this to the problem of other vaccines
19:17:25 <rhiaro> ... so it's not just covid
19:17:27 <rhiaro> ... polio and some others
19:17:37 <rhiaro> ... the government issues a vaccine certificate to parties
19:17:43 <rhiaro> ... this is part of the credentail community initiative
19:18:04 <rhiaro> ... the DIDComm use is primarily around making use of Ares RFC36/37 for issuance and proving over DIDComm
19:18:21 <rhiaro> ... Next is a production system, Verifiable Organizations Networks
19:18:31 <rhiaro> ... this is the first production system in the world tha tused DIDComm, it went live in late 2018
19:18:50 <rhiaro> ... and the use case for this system was the governmetn of british columbia wanting to issue business licenses - liquor licenses, health inspection certificates
19:19:08 <rhiaro> ... so they've not only built an dissued millions of credentials in production, they also created a public registry where these credentials could be discovered an dqueried
19:19:18 <rhiaro> ... in the context of DIDs we've had discussions about publicness of certain information relative to DIDs
19:19:30 <rhiaro> ... in this case the privacy issues don't apply and that's party why I thought it would be interesting
19:19:42 <rhiaro> ... all of the information they're turning into credentials is publicly available anyway, it's government information published in other forms
19:19:47 <rhiaro> ... DIDComm in this case was implemented in python
19:19:55 <rhiaro> ... lots of cool properties to that system, has been in prod for about 2 years
19:20:05 <rhiaro> ... Next is a bit different
19:20:15 <rhiaro> ... this is a product that I want to highlight, CredentialMaster
19:20:16 <brent> s/an dqueried/and queried/
19:20:24 <rhiaro> ... like many of us has been focussed on making VCs easier to use
19:20:32 <rhiaro> ... the thing notable about them is they have built an integration with salesforce
19:20:41 <rhiaro> ... which gives them a global scale story that is very interesting
19:21:02 <rhiaro> ... 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
19:21:10 <rhiaro> ... so they can actually track the status of credentials at scale
19:21:33 <rhiaro> ... if you had an institution that needed to knwo 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
19:21:41 <rhiaro> ... and do that at bulk scale, that's the business that CredentialMaster is in
19:21:45 <rhiaro> ... they support multiple VC ecosystems
19:21:58 <rhiaro> ... many of you know I have spent my energy in the hyperledger VC ecocsystme but CredentialMaster is agnostic
19:22:05 <rhiaro> ... hyperledger is only one of the VC types they want to ffer the world
19:22:10 <rhiaro> ... they also support multiple DID methods
19:22:14 <rhiaro> ... and use DIDComm through libraries
19:22:26 <rhiaro> ... making calls to DIDComm wrappers, I think javascript
19:22:37 <rhiaro> ... any questions?
19:22:53 <rhiaro> ... This is another production solution that is being used today
19:22:56 <rhiaro> ... at enterprise scale
19:23:02 <rhiaro> ... CULedger MemberPass technology
19:23:12 <rhiaro> ... it is a VC that is issued to somebody who is a member of a credit union
19:23:18 <rhiaro> ... its use case is login over DIDComm
19:23:23 <rhiaro> ... and DIDComm secure messaging
19:23:50 <rhiaro> ... 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 quesiton and conduct interviews
19:23:59 <yoshiaki> yoshiaki has joined #DID
19:24:05 <rhiaro> ... you could say I'd like to intervie wyou for your credit worthiness and post multiple choice questions and get certified answers over DIDComm
19:24:11 <rhiaro> ... that's an interesting uniqueness of that one
19:24:14 <manu> q+ to ask about what's changing in DIDComm v2
19:24:16 <rhiaro> ... Th enext is Anonyme labs
19:24:20 <rhiaro> ... they have an SDK along with this
19:24:33 <rhiaro> ... a different use case, it focuses on helping an individual create and manage personas in a very proactive way
19:24:39 <rhiaro> ... to maximise thier privacy
19:24:45 <brent> s/Th enext/The next/
19:25:03 <rhiaro> ... the screenshot highlights the fact you can createa  shopping persona and give yourself an arbitrary phone number in an arbitrary area code and project this persona in certain kinds of interactions
19:25:23 <rhiaro> ... 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
19:25:35 <rhiaro> ... but they have plans for some other credentials that they watn to support, or protocols they want to support
19:25:44 <brent> ack manu
19:25:44 <Zakim> manu, you wanted to ask about what's changing in DIDComm v2
19:25:53 <brent> q+manu
19:25:55 <agropper> q+
19:26:06 <rhiaro> daniel: Trustbloc is another DIDComm oriented activity
19:26:11 <rhiaro> ... this is an architecture diagram
19:26:19 <rhiaro> ... what makes this interesting is this is DIDComm using DID ion and sidetree
19:26:21 <dmitriz_> q+ to ask a newbie question re "how does didcomm relate to other secure messaging protocols, like Signal's whisper protocol"
19:26:23 <rhiaro> ... it's not using hyperledger indy at all
19:26:30 <rhiaro> ... it is using hyperledger fabric and Aries
19:26:36 <rhiaro> ... the language of implementation is Go
19:26:38 <rhiaro> ... most of the transport is http
19:26:51 <rhiaro> ... i think the universal resolver is used and some equivalence to the universal resolver that has been built in Go
19:26:56 <rhiaro> ... dbuc is saying they don't use ION
19:27:05 <rhiaro> ... but someone gave me the impression they do
19:27:10 <rhiaro> ... maybe not ION but just sidetree
19:27:23 <rhiaro> ... that's a farily different technology stack
19:27:35 <rhiaro> ... th eprimary use case in this ecosystem that securekey focus is on is KYC
19:27:46 <rhiaro> ... but now some parts that are not from securekey and not for KYC, not sure what their use cases are
19:27:55 <rhiaro> ... Kiva is a cool solution i production, they have 3.5 million wallets
19:28:00 <rhiaro> ... that are built on top of DIDComm support
19:28:08 <rhiaro> ... these are for government issued national IDs in sierra leone
19:28:21 <rhiaro> ... primarily trying to solve economic empowerment problems there, lending money, making payments, reporting things
19:28:40 <ivan> q+
19:28:42 <rhiaro> ... they started out on hyperledger indy but originaly 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
19:28:46 <rhiaro> ... using DIDComm mostly for VC uses
19:28:51 <rhiaro> ... possibly some secure messaging as well
19:29:07 <rhiaro> ... There's an NHS thing going on
19:29:17 <rhiaro> ... There's some research about DIDComm where the transport is the file system or email
19:29:22 <brent> ack manu
19:29:30 <rhiaro> manu: what are you most excited about for DIDComm v2?
19:29:39 <dbuc> We're all DIDCommies now
19:29:45 <rhiaro> daniel: 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
19:29:47 <brent> ack agropper
19:30:03 <rhiaro> agropper: i think of the world in terms of authorization - are there any examples or overlap with something like GNAP?
19:30:13 <rhiaro> daniel: there is bridge building between DIDComm and OIDC and SIOP stuff
19:30:20 <rhiaro> ... nature of that is not easy to explain in a minute
19:30:25 <ivan> q-
19:30:26 <dmitriz_> q-
19:30:33 <rhiaro> brent: others reach out directly to daniel with questions. Thanks very much daniel
19:30:49 <manu> +1, thank you Daniel!
19:30:53 <rhiaro> TOPIC: Greetings from the TAG
19:31:15 <rhiaro> brent: we're anticipating Hadley Beeman and Teresa O'Connor to join us
19:31:20 <drummond> Very nicely done, Daniel
19:33:43 <manu> q+
19:33:47 <markus_sabadello> q+
19:33:52 <manu> q- later
19:33:56 <rhiaro> brent: 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
19:34:08 <brent> ack markus_sabadello
19:34:12 <rhiaro> markus_sabadello: I'd be really interested in getting a summary from jonathan's presentation in the breakout, I couldn't attend
19:34:19 <drummond> +1 to that
19:34:39 <brent> ack manu
19:34:41 <rhiaro> manu: 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
19:34:46 <rhiaro> burn: we're not doing issue processing any more
19:35:24 <rhiaro> ... 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 befor we discuss again
19:35:30 <rhiaro> ... I like the idea of looking at the extra issues
19:35:37 <selfissued> I agree that we reached an energetic conclusion to the Abstract Data Model conversation
19:35:42 <rhiaro> ... one topoic is a quick revie wfrom jonathan the other is issues from editors
19:35:54 <rhiaro> brent: jonathan could you do a 5 minute review of you breakout?
19:35:56 <drummond> +1 to 5 mins with Jonathan and then issue processing
19:36:02 <rhiaro> Topic: Review of CDDL
19:36:37 <rhiaro> 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
19:36:51 <rhiaro> ... 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
19:37:08 <rhiaro> ... i think cddl could serve as an in between that doesn't replace infra but works synegistically making the ADM more concrete
19:37:12 <rhiaro> ... and allows for different representations
19:37:26 <rhiaro> ... cbor extends on json, it's a superset, includes additional information including bytes and has an extensions mechanism built in
19:37:35 <rhiaro> ... and a diagnostic notation for readability
19:37:42 <rhiaro> ... cddl is based on ABNF rules
19:38:08 <rhiaro> ... cddl is a normatively defined abnf like grammar for structured data
19:38:20 <rhiaro> ... the logic of how it works is you have a spec with production and consumption rules, with a specific name
19:38:25 <rhiaro> ... define sub grammars
19:38:33 <rhiaro> ... constrain the set of combinations of things
19:38:40 <rhiaro> ... in a way that uses abnf sub grammar with naming things as text strings
19:38:47 <rhiaro> ... cddl is a subgrammar of abnf rules that name them an dassign types
19:38:52 <rhiaro> ... the values can be a set of types or sequences
19:38:57 <rhiaro> ... but the top level producton of cddl is a type
19:39:04 <rhiaro> ... cddl specifies a constrained set of data items
19:39:20 <rhiaro> ... here are all of the representations, a video I'd encourage you to check out
19:39:22 <rhiaro> ... these are the building blocks
19:39:29 <kristina> https://www.youtube.com/watch?v=y46dARLUmmI
19:39:33 <rhiaro> ... the entire DID doc is in CDDL in a PR
19:40:01 <rhiaro> TOPIC: Greetings from the TAG
19:40:15 <rhiaro> brent: we set aside this time to give TAG an opportunity for feedback on the DID spec, and any questions
19:40:41 <dmitriz_> +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.)
19:40:47 <ivan> guests+ Tess_O'Connor
19:40:55 <manu> dmitriz_ -- I hope that was a joke -- :)
19:40:58 <jonathan_holt> my slides regarding CDDL:  https://ipfs.io/ipfs/QmX2pvFR6Ca7qQHeQn2wRUBv7LTdXAWQJf7AaJzayUZHPa/#/
19:41:12 <manu> because it's not possible to do that w/o rewriting very large portions of the spec.
19:41:21 <manu> and throwing out abstract values spaces.
19:41:29 <manu> and then causing things like CBOR-LD to break
19:41:39 <rhiaro> hober: I don't have anything to share offhand
19:41:46 <rhiaro> burn: do you have any questions?
19:42:17 <ivan> scribejs, set hober Tess_O'Connor
19:42:40 <dmitriz_> /me ah, sure. yeah, I of course don't want that.
19:42:54 <ivan> scribejs, set rossen Rossen_Atanassov
19:43:19 <ivan> guests+ rossen
19:43:27 <rhiaro> rossen: I'm just going to take a minute or two to get ready
19:43:48 <rhiaro> guests+ hadleybeeman
19:44:25 <rhiaro> hadleybeeman: I don't think we prepared becausae we thought we'd be taking questions from you but we'll figure it out
19:45:05 <rhiaro> rossen: issue 556 which is the design review request?
19:45:06 <rhiaro> brent: correct
19:46:45 <rhiaro> hadleybeeman: we have let you down. We did commit to get back to you before TPAC, apologies
19:46:53 <rhiaro> ... the virtual tpac has put us all in a discombobulated state
19:47:10 <rhiaro> ... 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?
19:47:23 <rhiaro> brent: jonathan and wayne and adrian were working on that
19:47:28 <rhiaro> ... status update?
19:47:45 <rhiaro> 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
19:48:05 <jonathan_holt> https://docs.google.com/document/d/13qLCZcks3OAb2V7GHcrSs8s9drA5OaqEPYPI1knmodc/edit#heading=h.mc2736ve71dk
19:48:06 <ivan> [tag issue](https://github.com/w3ctag/design-reviews/issues/556)
19:48:10 <rhiaro> hadleybeeman: for what i'ts 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
19:48:24 <manu> q+ to suggest that we come and present to TAG, if that would help.
19:48:26 <rhiaro> ... 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
19:48:34 <brent> ack manu
19:48:34 <Zakim> manu, you wanted to suggest that we come and present to TAG, if that would help.
19:48:49 <rhiaro> manu: a number of us have been in other WGs and through TAG review so we understand what to expect
19:48:59 <rhiaro> ... I'm wondering based on where we are if it would be helpful for us to come and present the work to the TAG
19:49:17 <rhiaro> ... 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
19:49:29 <rhiaro> ... not to say we meet regularly, but at least 2 or 3 touch points
19:49:40 <rhiaro> ... I'm afraid we're not going to get much use out of the TAGs review
19:50:00 <rhiaro> ... 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
19:50:14 <rhiaro> hadleybeeman: that makes a lot of sense to me in as much as we're the ones nominated as contacts for you
19:50:19 <rhiaro> ... getting a time when we can all meet is a challenge
19:50:26 <rhiaro> ... we're really keen to make sure everything is documented as part of the review
19:50:40 <rhiaro> ... 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
19:50:52 <rhiaro> ... What I think would be useful for me would be to have a chat about how the spe chas changed since you left the CG stage
19:51:02 <rhiaro> ... I think I had a godo handle on what was going on at that point but you've done a fair amoutn of work since then
19:51:10 <rhiaro> ... one of my intentions in wanting some additional time was to sort out that diff
19:51:17 <rhiaro> ... would be good for you to highlight it
19:51:26 <manu> q+ to suggest DID WG times that TAG can drop in on?
19:51:36 <rhiaro> hober: 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
19:51:45 <rhiaro> ... with a little bit of rationale about how you chose a direction
19:51:51 <rhiaro> ... one thing we look for is considered alternatives
19:51:55 <jonathan_holt> q+
19:52:04 <rhiaro> ... can be helpful to elucidate why your design is the way it is by showing where you could have gone but chose not to
19:52:07 <brent> ack manu
19:52:07 <Zakim> manu, you wanted to suggest DID WG times that TAG can drop in on?
19:52:29 <rhiaro> manu: 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
19:52:46 <rhiaro> ... 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
19:52:58 <rhiaro> ... 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
19:53:08 <rhiaro> rossen: is this the regular time
19:53:12 <rhiaro> manu: tuesdays at 11 eastern
19:53:31 <rhiaro> hober: that's probably a decent time for rossen and me but hadley is in europe
19:53:40 <rhiaro> hadleybeeman: we can work async if need be
19:53:46 <brent> ack jonathan_holt
19:53:59 <rhiaro> jonathan_holt: hadley I appreciate yoru comment that this is an introspective process of documenting, supposed to stir up thoughts
19:54:04 <rhiaro> ... and have an opportunity for us to jot them down
19:54:14 <rhiaro> ... I'm wondering ifyou have guidence for how to go through that process more iteratively
19:54:31 <rhiaro> ... 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
19:54:57 <rhiaro> ... 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 guidence of how to go through this?
19:55:17 <rhiaro> hober: the privacy interest group is the group at W3C charged with doing horizontal review of specs for privacy purposes
19:55:27 <rhiaro> ... the security and privacy questionnaire is a collaboration between the TAG and PING
19:55:47 <rhiaro> ... what we're trying to do with it, it's not an exhaustive document that captures every possibly concern, but a distinllation of our experience doing these reviews of things that often come up
19:56:09 <rhiaro> ... 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
19:56:23 <rhiaro> ... and then once you've done that that iteration can happen where we can have a converasation abotu what you discovered during that
19:56:28 <rhiaro> ... and you can go to PING and ask for a privacy review from them
19:56:33 <rhiaro> ... their process is different from ours
19:56:41 <rhiaro> ... the things they look for are different and they ahve different backgrounds and expertise
19:56:54 <rhiaro> ... you might as well get reviews from both of us
19:56:56 <rhiaro> ... that's where you start
19:56:57 <agropper> q+ to ask about influence of government ID initiatives on our privacy process
19:57:08 <rhiaro> ... the questionnaire isn't exhaustive, it's just stuff we've noticed a lot and that we wanted to make sure people think about
19:57:26 <rhiaro> ... 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
19:57:37 <rhiaro> ... it wouldnt surprise me if our questions aren't really geared toward the sorts of issues you've had
19:57:47 <rhiaro> ... maybe it's a better fit for technologies that are closer to standard web tech
19:57:50 <drummond> True, DIDs do take the Web in a new and exciting direction.
19:57:54 <rhiaro> ... this is an opportunity for us to improve the questionnarie as well
19:57:59 <rhiaro> ... i'd love for you think about what should we have asked
19:58:11 <rhiaro> ... how is this questionnaire not serving your needs or helping you reframe the possible security and privacy issues
19:58:17 <rhiaro> ... we want our reviews to be useful for everybody
19:58:38 <rhiaro> ... 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
19:58:46 <rhiaro> brent: we've got some good feedbackf rom you as far as next steps
19:58:56 <rhiaro> ... we can reach out to you for some time during our regular meetings for more specific feedback
19:59:02 <rhiaro> ... anything else we could provide at this point?
19:59:07 <rhiaro> ... what would help you most?
19:59:32 <rhiaro> hadleybeeman: when we were last looking at this I had the things I was interested, rossen did you have others?
20:00:01 <rhiaro> rossen: from my recollection, we did discuss in detail alternatives and what alternatives could be in the proposed explainer
20:00:09 <rhiaro> ... the way that you want to push DID forward
20:00:23 <rhiaro> ... 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
20:00:33 <rhiaro> ... the non-goals seem to cast umbrella of thing swe're not going to worry about
20:00:40 <rhiaro> ... there's a lot of technical detail and problems to solve
20:00:50 <rhiaro> ... we're just starting at the stage at which we assume DIDs are ready for use
20:01:18 <rhiaro> ... the point is when we go down and start figuring out, you did gret work already pushing your particular tech to the point wher eit is today, it was hard for us to piece together how you arrive at this stage, how you make these decisions
20:01:25 <rhiaro> ... and what were the alternatives considered along the way?
20:01:28 <rhiaro> ... something better but unobtainable?
20:01:32 <rhiaro> ... was this the only thing that cam eto mind?
20:01:47 <burn> q+
20:01:50 <rhiaro> hadleybeeman: that fits with my memory
20:02:12 <rhiaro> ... thanks for having us
20:02:18 <rhiaro> ... we're here to help where we can
20:02:35 <rhiaro> brent: we're officially out of time, I was going to steal 5 or 10.. to finish the q
20:02:38 <brent> ack agropper
20:02:38 <Zakim> agropper, you wanted to ask about influence of government ID initiatives on our privacy process
20:02:51 <rhiaro> agropper: governments around the world are looking for guidence on digital ID
20:03:03 <rhiaro> ... often mention self sovereign identity and our work in this group as an alternative
20:03:27 <rhiaro> ... 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?
20:03:36 <rhiaro> hober: in terms of privacy, ther'es the PING here at w3c
20:03:49 <rhiaro> ... who are a number of folks interested in privacy from across the consortium
20:04:24 <rhiaro> ... one thing that comes to mind as far as other groups is there's an ISO spec related to digital identity
20:04:38 <rhiaro> ... I'd be curiosu from a privacy standpoint and architectural, to hear about the relationship to that
20:04:40 <kristina> there is also an ISO TR on blockchain governance
20:04:45 <burn> q-
20:04:49 <rhiaro> ... what are the potential interoperability concerns or opportunities to collaborate?
20:04:55 <identitywoman> mDLs are a one trick pony relative to what we have
20:05:27 <rhiaro> burn: this is something for you to know - the work was incubated before it came to the WG
20:05:35 <rhiaro> ... and as a result with respect to your question about alternatives
20:05:52 <rhiaro> ... 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
20:05:58 <rhiaro> ... I think you may be asking for a different question now
20:06:07 <rhiaro> ... now that it's come into the group, what are the other decision we have discovered we need to make?
20:06:14 <rhiaro> ... ti woudl be good to understand which question yoru asking
20:06:25 <rhiaro> ... why was it started the way it was, vs what are things that you have since discussed and maybe chosen one direction over another?
20:06:41 <rhiaro> hober: the answer is both... the longer answer is incubation when successful is input into the standards process
20:06:47 <rhiaro> ... but it doesn't constrain the standards process
20:07:05 <rhiaro> ... 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
20:07:21 <rhiaro> ... so yes, your second point, decisions made since incubation and substantive changes that is very interesting to us
20:07:37 <rhiaro> ... but the first part is interesting that there may be fundamental decision taken during icubation that the WG has affirmed
20:07:45 <rhiaro> ... that it's decided we were on the right track when we were doing the earlier phase of this
20:07:48 <rhiaro> ... this is useful as well
20:07:57 <rhiaro> burn: we're definitely aware that incubation is the beginning of the standards process not the end
20:08:03 <rhiaro> ... as chairs we explained that to the group when we started
20:08:04 <kristina> @agropper https://www.iso.org/standard/76480.html this is hoped to help government adoption though this is not limited to identity
20:08:17 <rhiaro> ... 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
20:08:23 <rhiaro> ... the group has affirmed many of those decisiosn along the way
20:08:29 <rhiaro> ... tha'ts helpful to hear that thos eaffirmation pieces are of interest
20:08:55 <rhiaro> brent: thanks, we'll definitely be reaching out
20:09:55 <rhiaro> TOPIC: Prep for horizontal review
20:10:05 <rhiaro> brent: we have had some horizontal reivew
20:10:15 <rhiaro> ... i18n and a11y groups have reviewed the spec
20:10:20 <ivan> q+
20:10:23 <rhiaro> ... their feedback was no issues?
20:10:26 <rhiaro> ivan: i confirm
20:10:32 <brent> ack ivan
20:10:38 <rhiaro> ... they have essentially closed... I did the internationalisation one, I can't remember who did accessibility
20:10:45 <rhiaro> ... i18n clearly said they are happy
20:10:51 <rhiaro> ... same for a11y
20:11:16 <rhiaro> brent: the feedback we're still looking for, the TAG review has begun somewhat
20:11:22 <yoshiaki> yoshiaki has joined #did
20:11:26 <rhiaro> ... they will be helped by the security and privacy review being complete
20:11:37 <rhiaro> ... we've held off reaching out to PING and securiyt reviewers until that questionnaire is complete
20:11:43 <jonathan_holt> q+
20:11:44 <rhiaro> ... that's the biggest roadblock at this point
20:12:01 <agropper> q+
20:12:04 <rhiaro> ... I'm open to different possibilities for this section going forward. we could try to work through the privacy and security questionnaire concerns
20:12:12 <brent> ack jonathan_holt
20:12:22 <manu> +1 for getting privacy/security questionnaire done -- we need that done.
20:12:31 <rhiaro> jonathan_holt: mostly about documenting an dformalising a process for continuing review. Not about checkbox of having the questionnarie complete; ongoing self reflective process
20:12:36 <rhiaro> ... are we building the right technology
20:12:45 <rhiaro> ... what are the implications of that to society of how it might be implemented
20:12:47 <manu> q+ to the questionnaire needs to be done first? Is it?
20:12:49 <rhiaro> ... it's an ongoing conversation
20:12:56 <burn> jonathan_holt, not exactly.  We must provide a doc in order to start a review
20:12:57 <rhiaro> ... i've been vocal about my cocners about security vulnerabilities
20:13:05 <rhiaro> ... part of my frustration is lacking that outlet to capture those thoughts
20:13:12 <rhiaro> ... hard for me to formulate my thoughts in a soundbite
20:13:24 <burn> q+
20:13:40 <burn> q-
20:13:42 <rhiaro> ... 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
20:14:02 <brent> ack q+ to say yes, but we also need to finish the questionnaire
20:14:07 <brent> q+ to say yes, but we also need to finish the questionnaire
20:14:09 <brent> ack agropper
20:14:10 <rhiaro> agropper: I don't want to sound like I'm overstating thi spoint 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
20:14:13 <rhiaro> ... is not slowing down
20:14:18 <rhiaro> ... and i find that very concerning
20:14:30 <rhiaro> ... i am thrilled by th enumber of participants we have in this work and the fact that it's growing activley
20:14:46 <rhiaro> ... but i do want to point out that from my interactions in situations as broad as MyData
20:14:54 <rhiaro> ... there's really just no consideration for what's going on here
20:15:06 <rhiaro> ... in some cases there's actually negative consideration or suspicion
20:15:40 <rhiaro> ... I think that, and talking about privacy of course, there are certain aspects o fwhat we're doing in getting to CR that we wwant 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
20:15:46 <rhiaro> ... that we identify the top two or three things wrt privacy
20:15:52 <rhiaro> ... and document why we are making these decisions
20:16:10 <rhiaro> ... and I sort of feel like we keep pushing this issue to the next and next meanwhile the clock on the CR is running
20:16:20 <rhiaro> ... last night ultimatums about in 30 days it'll be clsoed and go into a later spec
20:16:25 <rhiaro> ... that's a very dangerous perspective
20:16:26 <brent> ack manu
20:16:26 <Zakim> manu, you wanted to the questionnaire needs to be done first? Is it?
20:16:35 <rhiaro> manu: I'm looking at the PING tracking issue
20:16:35 <manu> https://github.com/w3c/did-core/issues/291
20:16:41 <rhiaro> ... this is a requirement of w3c that we have this done
20:16:46 <rhiaro> ... we'v eknown we need to have it done for many months
20:16:48 <manu> https://docs.google.com/document/d/13qLCZcks3OAb2V7GHcrSs8s9drA5OaqEPYPI1knmodc/edit#
20:16:50 <rhiaro> ... I'm looking at the latest one, it is not done
20:17:15 <rhiaro> ... I hear you, jonathan, about privacy and security is continous, 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
20:17:22 <burn> The questionnaire is the entry requirement for review and discussion.
20:17:29 <rhiaro> ... we're supposed to submit this questionnarie to PING with plenty of time before to get review and back and forth so we're ready to go into CR
20:17:38 <drummond> q+ to ask specifically what needs to be done and who is volunteering to do it?
20:17:39 <rhiaro> ... is the questionnarie done? we cannot proceed until it is at least done and submitted to PING
20:17:42 <brent> ack brent
20:17:42 <Zakim> brent, you wanted to say yes, but we also need to finish the questionnaire
20:17:48 <rhiaro> brent: second what manu said
20:18:10 <rhiaro> ... 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
20:18:13 <manu> Yes, agreed.
20:18:14 <rhiaro> ... I don't believe anyone feels that way
20:18:18 <manu> but we have to take the first step
20:18:24 <manu> the first step of iterating is to take the first step
20:18:28 <manu> that's filling out the document!
20:18:40 <rhiaro> ... if we want to have an interative process whereby we analyse and improve the privacy and security characateristics of our spec, the first step in that process is getting the questionnaire filled out and submitted so the epxerts at PING can do a review
20:18:42 <identitywoman> 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.
20:18:46 <rhiaro> ... then well have feedback upon whcih to iterate
20:18:57 <rhiaro> ... I believe jonathan and adrian and wayne have done a good amount of work thus far
20:19:01 <jonathan_holt> q+
20:19:14 <rhiaro> ... the fact is that th equestinnaire is still not complete and we need to know what will it take to get it done?
20:19:14 <agropper> q+
20:19:18 <brent> ack drummond
20:19:18 <Zakim> drummond, you wanted to ask specifically what needs to be done and who is volunteering to do it?
20:19:22 <rhiaro> drummond: that was what i was going to say
20:19:32 <rhiaro> ... I think we made a lot of pgoress on some key decisions yesterday, around privacy
20:19:40 <rhiaro> ... I was wondering what needs to be done
20:19:49 <rhiaro> ... I see kaliya has volunteered to help, i'm also volunteering to help
20:19:59 <rhiaro> ... I want to see the proposals from yesterday incorporated into the spec as soon as possible
20:20:02 <rhiaro> ... I'm workin gon them this week
20:20:14 <rhiaro> ... to the extent that the volunteers working on the questionnaire can use our help, I want to understand who where when how
20:20:18 <brent> ack jonathan_holt
20:20:28 <rhiaro> jonathan_holt: there are 6 unanswered questions that we've posed to the group that we're waiting for answers
20:20:37 <rhiaro> ... they are active areas of discussion. if we can work through those and document our thought process
20:21:03 <rhiaro> ... 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 continously review this
20:21:09 <rhiaro> ... this is an ongoing ative area of discussion
20:21:38 <agropper> Can someone put the 6 questions in the IRC, please?
20:21:56 <rhiaro> ... my frustration this morning about th eresoution, 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 ot make the spec stronger
20:22:05 <brent> ack agropper
20:22:17 <manu> The six questions are here: https://docs.google.com/document/d/13qLCZcks3OAb2V7GHcrSs8s9drA5OaqEPYPI1knmodc/edit
20:22:17 <rhiaro> agropper: there are two large blockers as far as I can see
20:22:22 <justin_r> +1 to jonathan_holt's points on process and moving forward
20:22:26 <rhiaro> ... one is the service endpoints as it relates to privacy
20:22:36 <rhiaro> ... we need to be clear who we expect methods to represent
20:22:38 <manu> and there are a entire sections at the bottom that are missing
20:22:42 <brent> q?
20:22:46 <rhiaro> ... will there be some situations where there are counting on allow lists or deny lists of methods
20:23:17 <rhiaro> ... 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
20:23:21 <ivan> q+
20:23:30 <rhiaro> brent: I'd liek to see if we can answer these six questions
20:23:31 <brent> ack ivan
20:23:43 <rhiaro> ivan: let's be careful not to fall into the perfect is enemy of the good situation
20:23:51 <brent> +1 to ivan
20:24:00 <rhiaro> ... it's perfectly fine if the questionnarie is not answered and there are some open questions, but a large part is answered then send it oto the relevent groups
20:24:05 <rhiaro> ... make it very clear we are still working
20:24:12 <rhiaro> ... they may hav equestions and we can answer and it's not correct, etc
20:24:15 <rhiaro> ... we have to get the ball rolling
20:24:29 <rhiaro> ... 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
20:24:32 <rhiaro> ... it's not absolutely empty
20:24:36 <rhiaro> ... then we can work in parallel
20:24:38 <burn> q+
20:24:43 <rhiaro> ... it will take them severla weeks to schedule us as well
20:24:46 <brent> ack burn
20:24:52 <rhiaro> burn: this is not optional or up for discussion
20:24:57 <rhiaro> ... we must have th equestionnaire, even if it's imperfect
20:25:03 <rhiaro> ... let's see what we can do to get those questions done
20:25:13 <rhiaro> ... otherwise we will never finish this spec
20:25:29 <burn> s/this spec/this spec, by the process/
20:25:37 <rhiaro> brent: are we moving service discovery otu of DID core? No
20:26:08 <rhiaro> ... manu is answering questions in the doc
20:26:36 <rhiaro> ... what bounds will we add to DID methods and service endpoints?
20:26:43 <rhiaro> ... we haven't limited beyond no PII in DID doc, not sure if we can
20:27:01 <rhiaro> ... PING and TAG are not looking for a perfect spec, they just want to see we have thought about it and addressed it with guidence for implementers and mitigated as best we can
20:27:12 <rhiaro> ... Are web browsers assumed to be a common mode for our spec?
20:27:15 <rhiaro> ... No
20:27:27 <rhiaro> ... many instances where http isn't involved at all
20:28:02 <jonathan_holt> q+
20:28:11 <rhiaro> ... we have some answers now, if folks would like to add comments or additional information please do so
20:28:28 <rhiaro> ... all those who have volunteered to get the questionnaire done, are these answers sufficient?
20:28:38 <agropper> q+
20:28:41 <manu> +1 to removing biometrics
20:28:47 <identitywoman> +1
20:28:50 <rhiaro> jonathan_holt: I suggest we move biometrics from the spec and allow it as an extension or an alternate verification method
20:28:56 <rhiaro> brent: that's best raised as an issue on DID core
20:28:58 <brent> ack jonathan_holt
20:29:06 <brent> ack agropper
20:29:24 <rhiaro> agropper: i'm willing to take these answers and go with jonathan and wayne and complete the questionnaire to the best of our ability
20:29:28 <identitywoman> I'm also willing to help
20:29:30 <rhiaro> brent: please reach out to drummond and identitywoman
20:29:51 <rhiaro> ivan: is there a time? deadline? when we send this to PING?
20:30:05 <rhiaro> brent: those who have volunteered is this Friday reasonable?
20:30:17 <rhiaro> jonathan_holt: between the 5 of us a time before our tuesday meeting
20:30:18 <identitywoman> +1
20:30:20 <rhiaro> agropper: okay with me
20:30:25 <drummond> q+
20:30:29 <rhiaro> brent: by tuesday we'll have a complete security and privacy questionnarie?
20:30:30 <manu> q+
20:30:36 <rhiaro> agropper: yes, hoping kaliya and drummond are available
20:30:37 <brent> ack drummond
20:31:02 <rhiaro> drummond: 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
20:31:05 <rhiaro> brent: parallel would be just fine
20:31:18 <ivan> +1 to brent
20:31:21 <rhiaro> ... addressing privacy concerns is an iterative process and we will continue to do so and make things better
20:31:22 <brent> ack manu
20:31:35 <rhiaro> manu: I'm concerned about the timeline, section 3 threat models is not filled out at all, that's a significan amount of work
20:31:45 <rhiaro> ... I don't know if folks saying yes by next tuesday understood that that is where most of the work needs to be done
20:31:55 <rhiaro> ... work done is good, but do not underestimate threat models
20:32:02 <rhiaro> burn: by tuesday can this group give us a date?
20:32:10 <rhiaro> ivan: knowing that contacting PING can be done when things are still open
20:32:18 <jonathan_holt> q+
20:32:33 <rhiaro> burn: 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?
20:32:36 <rhiaro> drummond: makes sense to me
20:32:37 <rhiaro> agropper: yes
20:32:50 <jonathan_holt> q-
20:33:00 <rhiaro> brent: those who have volunteered to work, thank you
20:33:12 <rhiaro> ... no scribes for tomorrow yet..
20:33:23 <rhiaro> ... part of tomorrow, not for the first session
20:33:34 <rhiaro> ... tomorrow 10am eastern, thanks for coming
20:33:37 <ivan> zakim, end meeting
20:33:37 <Zakim> As of this point the attendees have been ivan, brent, rhiaro, kristina, dlongley, wayne, drummond, Eugeniu_Rusu_Jolocom, selfissued, markus_sabadello, kazuakiarai, manu,
20:33:38 <manu> Thank you Chairs, thank you Amy!!! for scribing!!
20:33:41 <Zakim> ... jonathan_holt, shigeya, Geunhyung_Kim, justin_r, JoeAndrieu, burn, agropper, dbuc, identitywoman, by_caballero___juan, Orie, danielhardman
20:33:41 <Zakim> RRSAgent, please draft minutes
20:33:41 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/03-did-minutes.html Zakim
20:33:44 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
20:33:45 <manu> And Markus!
20:33:47 <Zakim> Zakim has left #did
20:34:44 <ivan> rrsagent, draft minutes
20:34:44 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/03-did-minutes.html ivan
20:41:55 <ivan> rrsagent, bye
20:41:55 <RRSAgent> I see no action items