13:52:25 <RRSAgent> RRSAgent has joined #did
13:52:29 <RRSAgent> logging to https://www.w3.org/2024/09/04-did-irc
13:52:39 <Wip> rrsagent, draft minutes
13:52:41 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/04-did-minutes.html Wip
13:52:45 <Wip> rrsagent, make logs public
13:53:09 <Wip> Meeting: Decentralized Identifier Special Topic Call
13:53:22 <Wip> Chair: Will Abramson
13:53:26 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Sep/0000.html
13:55:25 <TallTed> TallTed has joined #did
14:00:48 <ivan> present+
14:01:06 <Wip> present+
14:01:06 <KevinDean> KevinDean has joined #did
14:01:09 <KevinDean> present+
14:01:29 <KevinDean> KevinDean has joined #did
14:02:04 <markus_sabadello> markus_sabadello has joined #did
14:02:53 <JoeAndrieu> JoeAndrieu has joined #did
14:02:59 <markus_sabadello> present+
14:03:00 <bigbluehat> bigbluehat has joined #did
14:03:12 <markus_sabadello> scribe+
14:03:12 <JoeAndrieu> present+
14:03:13 <dmitriz> dmitriz has joined #did
14:03:14 <dmitriz> present+
14:03:24 <manu> present+
14:03:31 <markus_sabadello> Will: This is going to be a more informal call, topic is controller document
14:03:43 <markus_sabadello> Will: Maybe manu can give an overview of the document
14:03:46 <bigbluehat> present+
14:03:55 <markus_sabadello> Will: This document was developed in VC WG, need to discuss relationship to our group
14:04:04 <markus_sabadello> Will: We are considering pointing to that document
14:04:41 <markus_sabadello> manu: In a controller document, you can list public key material. There are also service descriptions
14:04:54 <markus_sabadello> manu: Really public keys are called verification methods, since there are also other ways
14:05:08 <TallTed> Will -- Your audio is rather choppy. If you're using a wireless/battery mic (including earbuds), it might be good to switch to wire (including built-in)
14:05:09 <markus_sabadello> manu: Service descriptions tell you how to interact with the entity identified by the identifier
14:05:28 <markus_sabadello> manu: The concept started out as a DID document.
14:06:03 <markus_sabadello> manu: At some point, a subgroup of people felt that the concepts of DID documents could be generalized
14:06:13 <markus_sabadello> manu: In DID Core, this wasn't possible based on the rules
14:06:29 <markus_sabadello> manu: A subgroup in the VC WG tried to generalized the concept, starting from DID Core.
14:06:55 <markus_sabadello> manu: We also defined something in Data Integritiy. And VC JOSE CODE wants to use https URLs.
14:07:11 <markus_sabadello> manu: So you could use https URLs where previously you could only use DIDs.
14:07:24 <markus_sabadello> manu: Now the controller document spec exists in VC WG.
14:07:43 <markus_sabadello> manu: Probably this group here should be in charge of this document, but it doesn't really matter due to the overlap.
14:08:13 <ivan> -> The VC version of the controller document https://www.w3.org/TR/controller-document/
14:08:24 <markus_sabadello> manu: Since 2 weeks ago, a number of discussions started on the document that could result in something that is not aligned with what we intended in DID Core.
14:08:41 <markus_sabadello> manu: There are "discuss" labels on issues in the controller doc repo.
14:08:45 <markus_sabadello> manu: It's still very much aligned with DID Core.
14:09:19 <Wip> Wip has joined #did
14:09:19 <markus_sabadello> manu: Basically we would have to point sections from DID Core to the controller document specification, and say that it can be used with DIDs, e.g. in the "id", "controller", etc. fields.
14:09:31 <markus_sabadello> manu: All the properties defined in DID Core are also defined in the controller document spec.
14:09:47 <markus_sabadello> manu: We have moved DID Resolution to a separate spec.
14:10:03 <markus_sabadello> manu: In DID Core, we would point to the controller document spec and "subclass" it.
14:10:22 <burn> burn has joined #did
14:10:37 <markus_sabadello> manu: Issues that have been raised about what is the "controller" property, and what it means for a subject to have control, etc.
14:11:04 <markus_sabadello> manu: First question is, as a goal, do we want to re-use the controller document spec, or continue to evolve in parallel. After that we can go into specifics.
14:11:25 <markus_sabadello> Will: Let's discuss this for about 10 min if we want to re-use the spec.
14:11:31 <manu> q+
14:11:33 <markus_sabadello> q+
14:11:35 <Wip> ack markus_sabadello
14:11:38 <Wip> ack manu
14:11:48 <JoeAndrieu> q+
14:12:01 <ivan> q+
14:12:07 <Wip> q+
14:12:15 <markus_sabadello> manu: I thought it might be helpful to cover what happens if we don't. In that case, we would have a fork. The "controller document" might not be fully aligned with "DID document", and it might create confusion.
14:12:44 <markus_sabadello> manu: I don't see any hard in depending on the controller document, as long as some upcoming discussions don't hobble our ability to use it with DIDs.
14:13:03 <markus_sabadello> manu: There were some hints about anti-decentralization, e.g. we should depend on central repos for extensibility.
14:13:23 <burn> present+
14:13:41 <Wip> ack JoeAndrieu
14:13:42 <markus_sabadello> manu: I think at this point, if we don't take a dependency, we should have a very good reason. In that case, controller document should not go ahead.
14:13:50 <markus_sabadello> q+
14:14:01 <markus_sabadello> JoeAndrieu: I think we should try
14:14:12 <manu> scribe+
14:14:14 <markus_sabadello> JoeAndrieu: We'll have more say in the future of the controller document if we try to use it
14:14:16 <Wip> ack ivan
14:14:29 <markus_sabadello> ivan: There is also a very technical reason why we are almost forced to do that.
14:14:43 <markus_sabadello> ivan: The document also includes a formal vocabulary.
14:15:24 <markus_sabadello> ivan: That vocabulary is controlled by the VC WG. If we don't use it, then we would have to change our own terms URLs, we would have to change the context file, and it wouldn't be backwards compatbiel.
14:15:27 <Wip> ack Wip
14:15:30 <markus_sabadello> ivan: In a sense, we are force to do it.
14:15:40 <markus_sabadello> s/force/forced/
14:15:54 <ivan> s/compatbiel/compatible/
14:15:55 <manu> q+ to speak to "concrete representation" concerns.
14:16:01 <markus_sabadello> Wip: If we rely on controller document, and then if the controller decided to have a concrere representation, what would be the implications?
14:16:03 <Wip> ack markus_sabadello
14:17:14 <JennieM> JennieM has joined #did
14:17:26 <manu> markus_sabadello: I wanted to express that I'm in favor of trying to add dependency for controller documents. People are confused on DID Document vs. Controller document, good idea to do that. I also have a question on extensibility, which was just restructured. I assume that there is no conflict there w/ controller document... if controller document and vocabulary are controlled by VCWG, and DID WG has extensions, I assume it's fine. In general in
14:17:26 <manu> support of the alignment.
14:17:34 <Wip> ack manu
14:17:34 <Zakim> manu, you wanted to speak to "concrete representation" concerns.
14:18:24 <markus_sabadello> manu: Regarding concrete representation concerns.. There is a disagreement on one of the PRs about whether we will have a concrete representation for the controller document. We need to settle that in VC WG.
14:18:48 <markus_sabadello> manu: My impression was people wanted to use a plain JSON non-DID version. We have no media type for that.
14:19:14 <markus_sabadello> manu: So we need to decide if we are creating that and if it gets a media type. If it does, then that's okay. Then DID document will have its own media type.
14:19:33 <markus_sabadello> manu: I'm not concerned about the layering there and about concrete representations.
14:19:51 <markus_sabadello> manu: It's a discussion we need to have, but there are multiple ways forward.
14:20:19 <markus_sabadello> manu: Regarding extensions, where do they live. It could be part of VC extension, and we could move the DID-related extensions over there.
14:20:37 <ivan> q+
14:20:39 <markus_sabadello> manu: Or we have our did-extensions. We could say any property that is allowed on a DID document can be allowed on a controller document.
14:21:04 <markus_sabadello> manu: Other option is that we could have a separate controller-extensions repo.
14:21:17 <markus_sabadello> manu: It's an open question.
14:21:47 <markus_sabadello> manu: We should pick something and go with it, there ways through both topics.
14:21:48 <Wip> ack ivan
14:22:08 <markus_sabadello> ivan: Regarding disagreement between manu and I, we'll solve it.
14:22:29 <markus_sabadello> ivan: Regarding question by markus_sabadello, we already have a funny situation. Almost all terms are in the controller document or security vocabulary.
14:22:44 <markus_sabadello> ivan: As I remember, one term ended up in a different vocabulary.
14:22:51 <manu> q+ to speak to service descriptions, and what we want to do there.
14:23:04 <markus_sabadello> ivan: So we already have a case where a DID document may have properties that are not in the controller document, which I think is not a problem.
14:23:31 <markus_sabadello> ivan: Every time there is a new term, we should decide if it's DID-specific, or if we believe it is also usable for any other specification that may decide to use the controller document.
14:23:44 <Wip> ack manu
14:23:44 <Zakim> manu, you wanted to speak to service descriptions, and what we want to do there.
14:23:46 <markus_sabadello> ivan: I'm not worried about that
14:24:30 <markus_sabadello> manu: I'm not worried about it either. Due to the extensibility mechanism we have, there is a clean story. There is a full URI that describes the property. You don't have to worry about conflicts elsewhere.
14:24:46 <markus_sabadello> manu: We should have a discussion where the best place is for these discussions.
14:25:06 <markus_sabadello> manu: The specific examples regarding service endpoints is a really good one to figure out.
14:25:16 <markus_sabadello> manu: I think we should move service descriptions over to controller document.
14:25:34 <markus_sabadello> q+
14:26:02 <markus_sabadello> manu: People who didn't want to use DIDs did not want to use JSON-LD, and didn't need service descriptions.
14:26:12 <markus_sabadello> manu: We should move service descriptions over.
14:26:13 <Wip> ack markus_sabadello
14:26:36 <ivan> q+
14:26:37 <manu> markus_sabadello: Yes, I agree - service descriptions should be moved over. Historically, there are other examples of discovery formats where you have service descriptions or some equivalent concept.
14:27:12 <manu> markus_sabadello: In the core properties, there is already one property that's in a different namespace... `alsoKnownAs`, we had discussions with Activity Streams, so it's an example of a property that's defined elsewhere in a different group, in a different vocabulary.
14:27:15 <Wip> ack ivan
14:28:15 <markus_sabadello> ivan: There is a pragmatic reason that worries me about service descriptions. We are under time pressure in VC WG. In order to move to Rec, we need clear references.
14:28:27 <markus_sabadello> ivan: Controller document was relatively late in the process.
14:28:28 <manu> q+ to note time pressure on controller document
14:28:47 <Wip> ack manu
14:28:47 <Zakim> manu, you wanted to note time pressure on controller document
14:28:52 <markus_sabadello> ivan: If DID WG needs something in controller documents, it should happen fast
14:29:22 <markus_sabadello> manu: I think our timeline for controller documents was shifted recently, as many new issues have been opened.
14:29:48 <markus_sabadello> manu: Moving service descriptions over I think may be a challenge, but would be worth doing (vs. not doing).
14:30:10 <markus_sabadello> manu: If we are in agreement that architecturally speaking it makes sense, we should go ahead and try.
14:30:24 <markus_sabadello> manu: I don't think it will go into CR until maybe November.
14:30:49 <markus_sabadello> Wip: Seems there is consensus to use controller document, let's bring this to the main DID WG call.
14:31:13 <Wip> issue https://github.com/w3c/controller-document/issues/33
14:31:19 <markus_sabadello> Wip: for the rest of the call, let's focus on an issue 43 raised by David Chadwick
14:31:27 <Wip> https://github.com/w3c/controller-document/pull/42
14:31:34 <markus_sabadello> Wip: A PR was created to address this issue.
14:31:38 <manu> q+
14:32:01 <Wip> https://github.com/w3c/controller-document/issues/75
14:32:04 <Wip> ack manu
14:33:30 <markus_sabadello> JoeAndrieu: Regarding issue 75, there is a notion that I have pushed back fairly consistently, which is referring to the properties in the DID document as describing the subject. I think this is an error and confuses people.
14:33:55 <markus_sabadello> JoeAndrieu: Describing the subject is something VCs do, DID document shouldn't be a place where we make statements about the subject.
14:34:06 <markus_sabadello> JoeAndrieu: Its primary function is to express how to verify proofs.
14:34:16 <markus_sabadello> JoeAndrieu: It's about verifying actions and interactions.
14:34:26 <manu> q+
14:34:27 <markus_sabadello> JoeAndrieu: Received some feedback from Mike and Dave.
14:34:34 <Wip> ack manu
14:34:54 <markus_sabadello> manu: It seems JoeAndrieu is making good, concrete suggestions.
14:35:21 <markus_sabadello> manu: A bit of history.. DID documents were always meant to be general resources that existed in a global information graph. They are like any other node in an information graphs.
14:35:42 <markus_sabadello> manu: But they had certain useful pieces of information used for interactions, such as cryptogrpahy.
14:36:03 <markus_sabadello> manu: Nodes in the graph are identified by an identifier, and then you have relationships to verification material, which are keys that an entity controls.
14:36:44 <markus_sabadello> manu: I don't like the word "controller". There is pushback that we shouldn't talk about a global graph, but rather a specific thing.
14:37:00 <markus_sabadello> manu: I get concerned when people say VCs are different from DID documents from a data model perspective.
14:37:03 <markus_sabadello> q+
14:37:05 <JoeAndrieu> q+ to say if the representation of the global graph presents making statements about identifiers, it's the wrong context for DID Documents
14:37:34 <dlongley> https://github.com/w3c/controller-document/pull/42#issuecomment-2319121851 <-- i wrote about how we aren't making "statements about identifiers" here (and how that doesn't really make sense)
14:37:59 <markus_sabadello> manu: We break the information model that all this work has been based on. I think we can improve the language. But a DID document is a node in an information graphs, with relationships to verification methods, etc. You could merge it with a VC that speaks about the same identifiers. You have different levels of trust.
14:38:09 <markus_sabadello> manu: Maybe we should have called them resource documents instead of controller documents.
14:38:13 <Wip> ack markus_sabadello
14:39:10 <manu> markus_sabadello: My understanding is aligned with what Manu said - nodes in information graphs that can be merged. Traditionally, DID Documents have been used for specific content such as keys and service endpoints, mostly for privacy/considerations. However, over the years, all kinds of other information is included in the DID Document -- use cases related to organizational identity and things of that nature. The DID Document becomes more than just a
14:39:10 <manu> container for public keys.
14:39:11 <Wip> ack JoeAndrieu
14:39:11 <Zakim> JoeAndrieu, you wanted to say if the representation of the global graph presents making statements about identifiers, it's the wrong context for DID Documents
14:39:36 <markus_sabadello> JoeAndrieu: I'm not a big fan of this notion of a global knowledge graph. Because of Goedel's incompleteness theorem.
14:39:56 <markus_sabadello> JoeAndrieu: If we talk about a system of identifiers, it becomes challenging due to the "id" field in JSON-LD.
14:40:05 <markus_sabadello> JoeAndrieu: Identifiers are the core thing we need to talk about.
14:40:18 <KevinDean> +1
14:40:31 <dlongley> q+
14:40:33 <manu> JoeAndrieu: I'm not a big fan of this notion of a big fan of a global knowledge graph, mostly about Goedel's incompleteness issue... if we are talking about a system of identifiers, I think it's difficult to say things about identifiers. I think what we are talking about are identifiers. I love how JSON-LD gives us decentralized disambiguation, but all documents need to be reconstructable in a single knowledge graph, use mathematical cosntruct to put all
14:40:34 <manu> statements in graph, Difficult for me to square that.
14:40:45 <Wip> ack dlongley
14:41:24 <markus_sabadello> dlongley: An identifier is just a string of characters. It could have a certain shape such as a URL, but that's about all you're really talking about when it comes to the concept of identifier.
14:41:44 <markus_sabadello> dlongley: Controller documents let you work with resources that are related to other resources that have the identifier in it.
14:42:20 <markus_sabadello> dlongley: All actions related to a controller document, e.g. proving that you are allowed to do something, that can change. Different people can make claims about it. This doesn't have to happen in the DID document, it can be in a VC.
14:42:42 <markus_sabadello> dlongley: Saying that you interact with an identifier makes no sense, and you don't make statements about identifiers. You make those statements about the subject.
14:42:57 <markus_sabadello> dlongley: We're expressing that the entity has verification methods related to it.
14:43:14 <JoeAndrieu> q+ to say asserting that the verification methods relate to anything beyond the provable elements of the method is a guarantee error
14:43:18 <markus_sabadello> dlongley: When interacting with the other systems, using a resource identified by the id, you use the verification methods in those documents.
14:43:20 <Wip> ack JoeAndrieu
14:43:20 <Zakim> JoeAndrieu, you wanted to say asserting that the verification methods relate to anything beyond the provable elements of the method is a guarantee error
14:43:48 <markus_sabadello> JoeAndrieu: I don't think they allow you to make statements about reality. We have verification methods. Do you have specific cryptographic guarantees about what is proven.
14:44:06 <dlongley> q+ to say "this verification method is associated with a thing referred to by identifier X" is a statement about reality
14:44:07 <markus_sabadello> JoeAndrieu: If we make a statement about person X, whether this has validity about person X, this is what happens in VCs.
14:44:09 <manu> q+ to note that I'm not saying we /have/ to do the global knowledge graph thing... I'm concerned about preventing that interpretation and having no universal model.
14:44:25 <markus_sabadello> JoeAndrieu: For an identifier, we are saying how you verify certain proofs in relationship to the identifier.
14:44:32 <KevinDean> +1
14:44:32 <Wip> ack dlongley
14:44:32 <Zakim> dlongley, you wanted to say "this verification method is associated with a thing referred to by identifier X" is a statement about reality
14:44:46 <markus_sabadello> JoeAndrieu: DID documents are not about proving a certain individual.
14:45:22 <JoeAndrieu> q+ you cannot prove that assertion
14:45:54 <markus_sabadello> dlongley: What I'm trying to say is that the simple statement that the verification method is related to a thing, that IS a statement about reality. It's a very simple statement used to achieve certain goals. This is the kind of statement that belongs in a controller document. This doesn't mean anything about identity assurance, we don't have to
14:45:54 <markus_sabadello> bring this into the conversation.
14:46:08 <markus_sabadello> dlongley: Proving which person it is, that's totally different.
14:46:10 <Wip> ack manu
14:46:10 <Zakim> manu, you wanted to note that I'm not saying we /have/ to do the global knowledge graph thing... I'm concerned about preventing that interpretation and having no universal model.
14:46:38 <markus_sabadello> manu: JoeAndrieu I'm getting hung up on the belief that we are trying to create an equivalence between VCs and DID documents, and I don't think we're trying to do that.
14:46:53 <markus_sabadello> manu: The level of trust you have in a VC is different from a DID document.
14:47:09 <JoeAndrieu> q+ to say "statements about the referrent" = VC "statements about proofs related to the identifier" = did document
14:47:16 <markus_sabadello> manu: You may trust both of those, but I doubt the level of trust is equivalent. You may trust one more than the other.
14:47:17 <dlongley> +1 proving something "is true" isn't relevant here :) ... we're just expressing information.
14:48:16 <markus_sabadello> manu: Just because we say an identifier identifies a thing in the world, that's all we're doing. This doesn't mean you have to treat a DID document equivalently to VCs. It's possible to merge them into the same graph, but I don't think anyone is saying that you should do that by deafult.
14:48:35 <markus_sabadello> manu: It's similar to getting two VCs from different sources.
14:48:51 <markus_sabadello> manu: I'm most concerned about not having a model for thinking about it in this way.
14:49:14 <markus_sabadello> manu: If we say DID documents and VCs are totally different things, then we don't have a unified model anymore.
14:49:25 <dmitriz> q+
14:49:34 <markus_sabadello> manu: All information models have issues when getting down to provability and completeness of statements.
14:49:54 <markus_sabadello> manu: Unless those things actually apply to the problem set we're solving, I don't think we should bring them into the discussion.
14:50:13 <markus_sabadello> manu: They may be important philosophical concepts, but probably don't affect the code we write.
14:50:28 <Wip> ack JoeAndrieu
14:50:28 <Zakim> JoeAndrieu, you wanted to say "statements about the referrent" = VC "statements about proofs related to the identifier" = did document
14:51:08 <markus_sabadello> JoeAndrieu: Once we frame the properties as being about the referent, we get into a loop.
14:51:23 <markus_sabadello> JoeAndrieu: We need to make statements about identifiers. The VC doesn't make it easy. This is what Goedel's theorem is about.
14:51:36 <dlongley> i don't think we have anything to get around -- at least i don't understand the problem, everything seems fine to me :)
14:51:41 <markus_sabadello> JoeAndrieu: We can prove a proof with cryptographic closure. We cannot prove statement about reality.
14:52:04 <Wip> ack dmitriz
14:52:17 <markus_sabadello> JoeAndrieu: We don't interact with identifiers.
14:52:27 <markus_sabadello> dmitriz: Maybe a pointer analogy is useful in this discussion
14:52:44 <markus_sabadello> dmitriz: In programming languages we never describe properties of pointers, we just talk about what they point to.
14:53:14 <markus_sabadello> dmitriz: One of the places where controller docs are being used is decentralized social media... Mastodon, Bluesky, Threads, etc.
14:53:35 <markus_sabadello> dmitriz: In that world, accounts have "actor" profiles. Those profiles have acquired verification methods that the actors can sign statements with.
14:53:46 <markus_sabadello> dmitriz: This turns social media profiles into DID documents. They also use JSON-LD.
14:53:54 <markus_sabadello> dmitriz: We have this data point of it being used in the wild.
14:54:04 <markus_sabadello> dmitriz: This seems to mix VC and DID worlds.
14:54:26 <markus_sabadello> dmitriz: In these docs, you have both public keys, and statements about the entity
14:54:46 <manu> q+ to agree w/ Dmitri (what people are doing) and focus on concrete language.
14:54:50 <dlongley> +1 i don't think that's an information problem, but a privacy consideration
14:54:56 <markus_sabadello> dmitriz: In the DID WG we were very careful to not put other statements (PII) into the document, due to privacy concerns
14:55:09 <Wip> ack manu
14:55:09 <Zakim> manu, you wanted to agree w/ Dmitri (what people are doing) and focus on concrete language.
14:55:11 <markus_sabadello> dmitriz: But we have this data points in actor profiles of the hybrid use.
14:55:19 <JoeAndrieu> q+ yes. that usage is the problem, IMO
14:55:20 <markus_sabadello> manu: +1 to dmitriz
14:55:23 <JoeAndrieu> q+ to say yes. that usage is the problem, IMO
14:55:49 <markus_sabadello> manu: People are starting to do things that would have made us very uncomfortable a few years ago, to try to minimize what's in the DID docu
14:56:10 <markus_sabadello> manu: But in the AcitivityPub example, people put information into the profiles that are meant to be publis
14:56:20 <markus_sabadello> manu: It does fit in with the information graph we were talking about before
14:56:27 <dlongley> +1 to agree with that position, minimize what goes into the DID doc -- and a separation of concerns helps with privacy and interop; but none of this is a theoretical information problem, but rather these are practical concerns
14:56:44 <markus_sabadello> manu: Another way of looking at it is that the DID document could be considered a "self-asserted" VC, in a different format.
14:56:58 <markus_sabadello> manu: The "id" at the top-level is the unified information model.
14:57:32 <markus_sabadello> manu: To get concrete about this...
14:57:48 <markus_sabadello> JoeAndrieu: I think you just described exactly the conflation problem I have been trying to reverse.
14:57:58 <markus_sabadello> JoeAndrieu: DID docs and VCs feel similar, but they are not the same.
14:58:08 <markus_sabadello> JoeAndrieu: I don't think that model is the right model to think about DID docs
14:58:24 <dlongley> +1 i agree with Joe that DID docs and VCs are different and have different uses, but ultimately, both *happen* to make statements about things -- but that isn't what the difference is (or why there is a difference)
14:58:35 <markus_sabadello> JoeAndrieu: Identifiers are used to "pivot" between different contexts. I'm labeling an identifier in a DID document, so that I can recognize it in VCs and verify proofs.
14:58:47 <markus_sabadello> JoeAndrieu: Imagining that they are somehow the same thing, that is the root of the tension
14:59:11 <dlongley> -1 that the "they are the same thing is the root of the problem", i think the root is elsewhere :)
14:59:25 <markus_sabadello> manu: That's a good summary of the disagreement.  But I see it as a non-issue.
14:59:32 <dmitriz> also disagree with Joe that DID Documents are identifiers. they're documents, not identifiers.
14:59:48 <markus_sabadello> JoeAndrieu: I think dmitriz's example in ActivityPub is the problem with the language we are using.
14:59:57 <manu> Hmm, I thought the ActivityPub usage was just fine :/
15:00:08 <markus_sabadello> JoeAndrieu: We're multiplying the problem if other groups use it like this.
15:00:24 <markus_sabadello> Wip: We will be discussing this at TPAC.
15:00:30 <markus_sabadello> Wip: Thanks everyone.
15:00:41 <dlongley> +1 to the conversation; i think the boundary is privacy and whether how/why you need to decouple statements in separate containers, not what is being talked about
15:00:51 <manu> yes, also +1 to that ^
15:01:13 <TallTed> present+
17:07:21 <Zakim> Zakim has left #did
17:30:02 <tzviya_> tzviya_ has joined #did