16:15:11 <RRSAgent> RRSAgent has joined #did-topic
16:15:11 <RRSAgent> logging to https://www.w3.org/2020/11/19-did-topic-irc
16:15:14 <Zakim> RRSAgent, make logs Public
16:15:15 <Zakim> please title this meeting ("meeting: ..."), ivan
16:15:25 <ivan> Meeting: DID WG Topic Call on Equivalence Properties
16:15:26 <ivan> Chair: brent
16:15:26 <ivan> Date: 2020-11-19
16:15:26 <ivan> Agenda: https://www.w3.org/mid/CAHR74YVTwc9AWHxy5caeqY3XB8FxtrA-sFcb1MNQ3_7Wz7GUuA@mail.gmail.com
16:15:26 <ivan> ivan has changed the topic to: Meeting Agenda 2020-11-19: https://www.w3.org/mid/CAHR74YVTwc9AWHxy5caeqY3XB8FxtrA-sFcb1MNQ3_7Wz7GUuA@mail.gmail.com
16:26:27 <dbuc> dbuc has joined #did-topic
16:52:00 <ivan> ivan has joined #did-topic
16:59:01 <brent> brent has joined #did-topic
16:59:26 <dbuc> present+
17:01:00 <jonathan_holt> jonathan_holt has joined #did-topic
17:01:01 <dlongley> present+
17:01:13 <markus_sabadello> markus_sabadello has joined #did-topic
17:02:04 <TallTed> TallTed has joined #did-topic
17:03:03 <markus_sabadello> present+
17:03:05 <markus_sabadello> scribe+
17:03:17 <brent> present+
17:03:17 <TallTed> I'm sure the zoom password is somewhere in the messages about this meeting, but I'm failing to find it. Can someone DM it to me please?
17:03:17 <manu> present+
17:03:22 <rhiaro> present+
17:03:27 <markus_sabadello> brent: Make sure you present+ yourself
17:03:32 <ivan> present+
17:03:40 <TallTed> tnx brent
17:03:43 <jonathan_holt> present+ jonathan_holt
17:04:07 <markus_sabadello> topic: Equivalence properties
17:04:20 <ivan> present+ TallTed
17:04:25 <drummond> drummond has joined #did-topic
17:04:29 <dmitriz> dmitriz has joined #did-topic
17:04:31 <burn> burn has joined #did-topic
17:04:33 <drummond> present+
17:04:36 <dmitriz> present+
17:04:36 <markus_sabadello> brent: If noone is opposed, dbuc can walk us through the current status of this
17:04:37 <burn> present+
17:04:55 <markus_sabadello> dbuc: We have a PR out for 2 properties that bring the level of trusted equivalence for a variety of needs
17:05:12 <markus_sabadello> dbuc: I had a presentation at TPAC
17:05:22 <markus_sabadello> brent: If you can walk people through the PR, that would be helpful
17:05:29 <Orie> Orie has joined #did-topic
17:06:02 <markus_sabadello> dbuc: The first property is "sameAs".. A DID method can define different forms of a DID that are logically equivalent.
17:06:11 <markus_sabadello> dbuc: One example is if the DID changes before registration and after registration
17:06:25 <markus_sabadello> dbuc: In this case, the DID method may specify multiple DIDs that are logically equivalent
17:06:46 <brent> PR: https://github.com/w3c/did-core/pull/431
17:06:52 <markus_sabadello> dbuc: Each sameAs DID must be within the same method
17:07:07 <markus_sabadello> dbuc: DID method must guarantee that DIDs are logically equivalent
17:07:24 <markus_sabadello> dbuc: A relying party must retain the DIDs, e.g. in a database
17:07:38 <ivan> q+
17:07:49 <brent> ack ivan
17:07:49 <manu> q+ to ask why this is not resolver metadata?
17:08:17 <markus_sabadello> ivan: I would prefer not to use the "sameAs" term. Either this is owl:sameAs and you say it, or it's something different
17:08:34 <markus_sabadello> ivan: The current text in the PR does more harm than good, it doesn't make sense to create such problems
17:08:35 <brent> ack manu
17:08:35 <Zakim> manu, you wanted to ask why this is not resolver metadata?
17:08:35 <markus_sabadello> dbuc: I agree
17:08:37 <dmitriz> +1 to what Ivan said.
17:08:41 <markus_sabadello> manu: I have 2 questions..
17:08:44 <Orie> +1 to ivan as well
17:08:45 <dbuc> +1 to Ivan
17:08:52 <drummond> So what should we use? equivalentID?
17:08:53 <dbuc> Well, not exactly
17:08:53 <markus_sabadello> manu: I agree with ivan this is owl:sameAs, I think everyone agrees
17:09:12 <markus_sabadello> manu: I'm concerned about this being expressed as a property in the DID document as opposed to DID resolver/document metadata
17:09:23 <markus_sabadello> manu: This is asserted by the DID method, not DID subject or controller
17:09:25 <dlongley> q+ to talk about use case and make a suggestion so people are aware/can consider it
17:09:46 <markus_sabadello> manu: If we enable the controller to assert this, then this can lead to security problems, e.g. taking over some else's DID, if this property gets injected
17:09:47 <Orie> q+ to note that did methods are still responsible for security
17:09:52 <dbuc> q+
17:09:56 <dmitriz> +1 to manu's point (that sameAs belongs in metadata not in the did doc itself)
17:10:01 <markus_sabadello> manu: It may be impossible to do this in did:web, since the DID method cannot assert this, only the controller
17:10:06 <dbuc> DID Web still requires a resolution step
17:10:14 <dbuc> which is where this would be excluded
17:10:26 <brent> ack dlongley
17:10:26 <Zakim> dlongley, you wanted to talk about use case and make a suggestion so people are aware/can consider it
17:10:28 <markus_sabadello> manu: I understand the use case, I think it's very dangerious as a property, but can work as metadata expressed purely by the DID method
17:10:38 <jonathan_holt> q+
17:10:53 <markus_sabadello> dlongley: Before we get too deep into technical details, I'd like to talk about the use case a bit more, to make sure we consider alternative solutions
17:11:12 <markus_sabadello> dlongley: My understanding is the use case is to hand DIDs to a user before the DID is registered, so that later it can be resolved
17:11:20 <manu> q+ to discuss burden on Relying Parties... N-to-one mappings.
17:11:28 <markus_sabadello> dlongley: There may be a simpler alternative.. The additional information can be expressed as VCs during an initial information.
17:11:39 <dbuc> That's asking for handoff failures and all sorts of other protocol juggling
17:11:52 <dbuc> and I have to recreate that across all forms of transport handoffs
17:11:54 <selfissued> selfissued has joined #did-topic
17:11:56 <brent> ack Orie
17:11:56 <Zakim> Orie, you wanted to note that did methods are still responsible for security
17:12:08 <manu> dbuc, you just need to implement Verifiable Credentials...
17:12:17 <markus_sabadello> Orie: I think dlongley is responding the second property regarding the applicability of VCs
17:12:20 <manu> (which you're going to do anyway)
17:12:24 <selfissued> present+
17:12:35 <markus_sabadello> Orie: Regarding the first property, this is about equivalent identifiers..
17:12:52 <markus_sabadello> Orie: Any DID method could construct RDF triples that are bad, you are 100% trusting the DID method
17:13:10 <markus_sabadello> Orie: Regarding did:web, there is acknowledgement that the DID controller has more authority
17:13:13 <dbuc> No, don't need to 'just implement VCs'
17:13:29 <dbuc> you need whole protocols for what they mean across all the envelopes
17:13:33 <dbuc> like OIDC, DID Comms
17:13:48 <manu> q+ to note attack -- I can take over someone else's DID on another ledger with this mechanism.
17:14:02 <markus_sabadello> Orie: I think it is a complete misunderstanding, it's a contradiction to look at a single property and say it has security issues, but others don't. Those other properties are at least as important as others, and you are still trusting the DID method to return the completely
17:14:10 <drummond> I agree with Orie. It actually feels more dangerous to trust something outside the DID document for a sameAs equivalence assertion.
17:14:18 <brent> ack dbuc
17:14:24 <markus_sabadello> Orie: It's incorrect to look at individual properties to be more or less security. Instead you should consider the security properties of the DID method as a whole
17:15:02 <drummond> q+ to agree with Orie
17:15:10 <manu> dbuc, no, you don't need to do that.
17:15:13 <markus_sabadello> dbuc: "Just do it through VCs" is a simplification of a very complex task. I have to codify a well-known semantic VC, publish it, go through OIDC/DIDComm/CHAPI to hand it off correctly, etc.
17:16:13 <markus_sabadello> dbuc: If done with VCs it has no force. We want people to rely on it consistently.
17:16:17 <dlongley> dbuc, no you're just announcing the additional information that can't be computed from the DID itself (non-root key), e.g., a service endpoint VC... which may be a very common VC.
17:16:23 <brent> ack jonathan_holt
17:16:26 <dmitriz> q+ to add a note on consistency
17:16:46 <markus_sabadello> jonathan_holt: owl:sameAs implies that the type = individual
17:16:51 <dbuc> I don't think it needs to be Owl sameAs
17:16:55 <manu> owl:sameAs does not imply that the thing is a person.
17:17:06 <dlongley> q+ to say i have a response to daniel, but will save it for 'canonicalId'
17:17:08 <drummond> Correct.
17:17:09 <markus_sabadello> jonathan_holt: I can imagine a bank created a DID for me and aggregates my other identities that I wanted to be pseudo/anonymous.
17:17:21 <brent> ack manu
17:17:21 <Zakim> manu, you wanted to discuss burden on Relying Parties... N-to-one mappings. and to note attack -- I can take over someone else's DID on another ledger with this mechanism.
17:17:21 <markus_sabadello> jonathan_holt: There may be security vulnerabilities, but also ethical dilemmas in the implementation.
17:18:03 <markus_sabadello> manu: There as also the burden on relying parties. Before, a RP didn't have to keep identifiers that are equivalent. I think it's a bad direction to now put this burden on RPs.
17:18:13 <dlongley> q- to wait for `canonicalId` discussion to respond
17:18:21 <jonathan_holt> from w3c.org:  "The built-in OWL property owl:sameAs links an individual to an individual. Such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity"."
17:18:32 <selfissued> q+
17:18:40 <markus_sabadello> manu: The attack is that I can take over your DID by asserting a sameAs in a DID method that is badly implemented. All I need to know is your DID, I need to create a fake DID that accepts it, or find a site where the implementation is slightly broken.
17:18:42 <jonathan_holt> individual = type person
17:18:48 <dbuc> I love how we assume the DID method is competent enough to do all the crypto right, but can't not print a property in a JSON doc
17:19:00 <rhiaro> jonathan_holt: I think that use of 'individual' is referring to any single entity, rather than individual as in person
17:19:18 <markus_sabadello> manu: This also means you can take over my DID, but I don't care. I want to take over your account; by using the sameAs property it's easy to do that. There is a serious security vulnerability
17:19:22 <brent> q
17:19:26 <markus_sabadello> q+
17:19:32 <brent> ack drummond
17:19:32 <Zakim> drummond, you wanted to agree with Orie
17:19:51 <markus_sabadello> drummond: To jonathan_holt, sameAs has nothing to do with being a person. It is just a statement of equivalence.
17:19:59 <manu> dbuc, the difference here is that this property doesn't talk about YOU, it talks about someone/something else.
17:20:28 <markus_sabadello> drummond: I believe manu has a point that equivalence properties can be an attack vector. Initially in the DID spec we had an equivalence property, but we removed it in the next version, because there are all kinds of attacks.
17:20:53 <markus_sabadello> drummond: Now we are reaching a level of maturity, I believe we have to tackle these. As dbuc has articulated, there are some really good reasons.
17:21:17 <markus_sabadello> drummond: While working with dbuc on the initial text, when looking the attacks, we realized that DID methods either support this property or not.
17:21:47 <dbuc> q+
17:21:52 <markus_sabadello> drummond: You can blocklist any DID methods that don't support these properties correctly.
17:22:01 <dbuc> Just put a metadata field in that says you support the prop
17:22:17 <dbuc> so it requires an explicit TRUE in there to be relied upon
17:22:19 <markus_sabadello> drummond: Communicating this information through another channel also introduces security risks, that you don't have if it's in a DID document.
17:22:19 <brent> this highlights how important DID Method security is
17:22:22 <brent> ack dmitriz
17:22:22 <Zakim> dmitriz, you wanted to add a note on consistency
17:22:36 <markus_sabadello> dmitriz: I wanted to challenge the claim that sameAs belongs in DID Core and the DID document.
17:22:59 <markus_sabadello> dmitriz: From everything that has been said so far, the meaning of sameAs is drastically different for each DID method.
17:23:22 <brent> ack selfissued
17:23:25 <markus_sabadello> dmitriz: The consistency argument is arguing in the reverse. Methods do not use this term consistently. This is an argument against including it in DID Core and the DID document.
17:23:27 <dbuc> The property language does unify it
17:23:41 <ivan> present+ selfissued
17:23:44 <dbuc> they must use it the way it is specified
17:23:56 <manu> q+ to note that sameAs talks about other things not directly related to DID Document / DID Subject.. that's what makes it different than the other properties we've talked about.
17:24:14 <markus_sabadello> selfissued: I want to respond to what manu said about DID methods using this property. If you trust a DID, you trust all aspects of it. It doesn't matter if there is one extra property that you are also trusting. This doesn't increase the threat surface.
17:24:20 <rhiaro> scribe+
17:24:24 <brent> ack markus_sabadello
17:24:48 <rhiaro> markus_sabadello: backthen when we had the discussion about metadata, we were considering the difference between properties guaranteed by the DID method and proeprties asserted b the controller
17:24:51 <rhiaro> ... eg. the created property
17:24:58 <rhiaro> ... that could sometimes be asserted by the controller but sometimes by the DID method
17:25:20 <rhiaro> ... we ended up deciding we would not put properties into different buckets depending on whether it's guaranteed by the method or asserted by the controller, it's in the DID doc or metadata or resolution metadata
17:25:31 <rhiaro> ... but if you want to know if it's asserted by the controller or the method then you have to read the DID method spec
17:25:35 <brent> q?
17:25:35 <rhiaro> ... it depends on the DID method
17:25:40 <markus_sabadello> scribe+
17:25:41 <brent> ack dbuc
17:26:17 <markus_sabadello> dbuc: I echo the same thing that everyone else said. If you want an extra layer of security. In did:web, as a resolver you get a DID document from a server, but you still have to wrap metadata around it.
17:26:30 <markus_sabadello> dbuc: You could put a boolean value in the metadata to say if you are going to use it.
17:26:44 <markus_sabadello> dbuc: As a method, you can say that you are affirmatively using this.
17:26:45 <Orie> whats more likely to be exploited: prototype pollution via __proto__ or owl:sameAs via semantic logical processors?
17:27:03 <Orie> the ADM will preserve both.
17:27:04 <brent> ack manu
17:27:04 <Zakim> manu, you wanted to note that sameAs talks about other things not directly related to DID Document / DID Subject.. that's what makes it different than the other properties we've
17:27:07 <Zakim> ... talked about.
17:27:23 <brent> q+ to ask where do we go from here?
17:27:31 <Orie> alsoKnownAs talks about another entity.
17:27:33 <dlongley> +1 there's a difference in "isolation" ... is it about the DID Doc/DID subject or something *outside* of it
17:27:36 <markus_sabadello> manu: The different thing about sameAs is that you are talking about another entity. We don't do that with the other properties. The other properties are about verification methods.
17:27:41 <dbuc> That's the entire point of equivalence
17:27:50 <markus_sabadello> manu: controller is the only thing that's close to sameAs, but that is cryptographically authenticated
17:27:51 <Orie> service endpoints describe other entitities
17:27:55 <dbuc> q+
17:27:57 <drummond> "controller" absolutely talks about another entity
17:28:17 <markus_sabadello> manu: This would be the only property that is not cryptographically authenticated and refers to another entity. This is a security issues, I'm going to -1 this
17:28:33 <dlongley> drummond, asserting someone else can act on your behalf is different from saying you can act on their behalf
17:28:44 <dlongley> wrt "controller"
17:28:56 <markus_sabadello> manu: I see two ways to address this: 1. Make sure it's bidirectional, 2. Make it something that's asserted by the DID method, this would be safer, so people can't just inject sameAs. It wouldn't require extra logic in DID document processing.
17:29:00 <brent> ack brent
17:29:00 <Zakim> brent, you wanted to ask where do we go from here?
17:29:11 <drummond> I'm not saying there's not a security issue, I'm just saying we can address it.
17:29:37 <markus_sabadello> brent: My proposal is that we actively work toward a solution that's acceptable for everyone
17:29:40 <Orie> If there is a security issue it applies to 100% of the properties that a did method / controller might include.... including xss / prototype pollution / sql injection
17:30:05 <markus_sabadello> dbuc: With regard to plugging the security problems. What would putting an affirmative "true" boolean in the metadata not cover?
17:30:13 <brent> ack dbuc
17:30:26 <ivan> q+
17:30:34 <markus_sabadello> manu: We should explore it, but I think it's a hack, I think moving the sameAs in the metadata would be safer.
17:30:43 <Orie> q+ to discuss the reasons why people avoid the metadata
17:30:47 <drummond> q+ to talk about the two options RE security - method verification and bidirectional resolution
17:30:52 <brent> ack ivan
17:31:12 <dlongley> i think we're conflating `sameAs` and `canonicalId` again ... dbuc, it's only `canonicalId` where you're making people "use it", vs. it just being there.
17:31:13 <dbuc> If you're telling me I can put something in the metadata that all MUST adhere to it?
17:31:18 <markus_sabadello> ivan: It's just a question, I think I remember you said at the F2F, for sameAs, both DIDs connected via sameAs must be in the same method?
17:31:23 <dlongley> when you talk about "making RPs" do something
17:31:24 <markus_sabadello> drummond: Yes that's correct
17:31:39 <dbuc> Can we not get caught up on the name?
17:31:41 <markus_sabadello> ivan: If this is owl:sameAs, then you cannot make such a restriction. Both could be any IRI.
17:31:51 <dbuc> Change it to sameBananaOctupusAs
17:31:53 <dlongley> dbuc, yes, that would be great, there are two concepts
17:32:00 <brent> ack Orie
17:32:00 <Zakim> Orie, you wanted to discuss the reasons why people avoid the metadata
17:32:01 <drummond> Then we should change the name to equivalentID
17:32:04 <markus_sabadello> ivan: You cannot put a restriction on something that's already defined and used out there.
17:32:16 <brent> ack drummond
17:32:16 <Zakim> drummond, you wanted to talk about the two options RE security - method verification and bidirectional resolution
17:32:34 <dlongley> q+
17:32:35 <markus_sabadello> drummond: I think ivan has a good point; we can give the property a different name. E.g. equivalentId or other name that works.
17:32:58 <dbuc> I agree
17:33:03 <manu> I disagree :)
17:33:06 <dbuc> it makes it less reliable outside
17:33:07 <markus_sabadello> drummond: I don't think the security vulnerability is any different if you put it in metadata instead of DID document.
17:33:28 <markus_sabadello> drummond: One option is the resolver verifies the DID method supports equivalence properties or not. The other option is bidirectional resolution.
17:33:37 <dbuc> q+
17:33:41 <dbuc> not always possible to do that
17:33:44 <brent> ack dlongley
17:33:47 <markus_sabadello> drummond: If the property is present, the resolver can resolve the equivalent ID to verify they are cross-referenced. I think we should discuss this.
17:34:20 <manu> equivalentDidMethodId and preferredDidMethodId
17:34:37 <markus_sabadello> dlongley: Let's make sure we don't conflate 2 concepts. One concept is an equivalence statement (potentially by the controller) that could be completely ignored. The other concept is canonicalId where we impose a requirement to the use of the DID document to use the canonical identifier.
17:34:44 <brent> ack dbuc
17:34:47 <Orie> q+ to restate the first property
17:35:02 <manu> q+ to note that saying "I control this" vs. "This can control me" are very different from a security perspective.
17:35:02 <markus_sabadello> dbuc: They both impose something. The RP must retain the equivalent identifier.
17:35:38 <manu> q+ to suggest -- equivalentDidMethodId and preferredDidMethodId
17:35:46 <markus_sabadello> dbuc: They both have some requirements. That's a good thing. In other protocols like OpenID, if they are not implemented consistently, then with some RPs you can use this and with others you can't.
17:35:49 <dlongley> q+ to ask for the mitigation of a concrete attack
17:36:05 <markus_sabadello> dbuc: If this is not strongly specified, it won't be reliable.
17:36:51 <markus_sabadello> dbuc: In Sidetree DIDs there is an identifying operation that is pointed out via the block number and the number of the operation. You could even resolve these numbers down to a DID that is 3 emojis, and that could be your DID. This will logically translate to an equivalent identifier.
17:37:34 <brent> ack Orie
17:37:34 <Zakim> Orie, you wanted to restate the first property
17:37:39 <markus_sabadello> dbuc: Someone said we're currently using base64 strings for DIDs, and we can simply switch to base58 strings later. But this doesn't work! You have to get this right at inception, because you can't change the identifiers later.
17:38:08 <manu> q+ to note usefulness for value prop, its the implementation that's problematic.
17:38:28 <markus_sabadello> Orie: As a DID method implementer, I should be able to express equivalent identifiers for the same logical subject in a way that is unique and I can make statements on how other parties should treat these identifiers. dbuc's example of base64 and base58 is a good example of this.
17:38:53 <markus_sabadello> Orie: As a DID method, how would you do that? It's very relevant to IPLD, they switched. We are asking for DID methods to be able to support this.
17:39:05 <dmitriz> I don't get the base-encoding arguments. Doesn't multibase take care of this?
17:39:21 <markus_sabadello> Orie: The challenge is, is this metadata, or does it belong in the DID document. This is placed by the DID method or controller, it varies by the DID method.
17:39:25 <dbuc> "We're going to get this perfect now and never need to change a string for 50 years" <-- excuse me while I express my wild skepticism
17:39:41 <markus_sabadello> Orie: One example is @context, the DID controller can often not control this, the DID method does.
17:39:47 <brent> ack manu
17:39:47 <Zakim> manu, you wanted to note that saying "I control this" vs. "This can control me" are very different from a security perspective. and to suggest -- equivalentDidMethodId and
17:39:50 <Zakim> ... preferredDidMethodId and to note usefulness for value prop, its the implementation that's problematic.
17:40:07 <dbuc> It's not going to have the same effect
17:40:14 <Orie> implemetation of did methods is out of scope for this WG
17:40:18 <Orie> ^^ chairs?
17:40:26 <dbuc> q+
17:40:41 <markus_sabadello> manu: I don't think anyone is challenging the value of this property. This is not what's being said. It's the implementation. The spec text as currently written has a vulnerability. We have some options how it can be addressed. At this point I think this is NOT sameAs.
17:40:57 <markus_sabadello> manu: I suggest alternative names: equivalentDidMethodId and preferredDidMethodId
17:41:31 <markus_sabadello> manu: I think there is a difference between this and "controller". The difference is "I control this" vs. "This controls me". The security parameters are very different
17:41:51 <markus_sabadello> manu: If we move this into metadata, and make sure only the DID method can assert this, then I may agree with this.
17:42:02 <brent> ack dlongley
17:42:02 <Zakim> dlongley, you wanted to ask for the mitigation of a concrete attack
17:42:34 <markus_sabadello> dlongley: I think we're missing a requiement on DID methods to reject the sameAs property. It must be rejected by DID methods if the DID method cannot control it. E.g. the did:web method should reject this.
17:43:25 <markus_sabadello> dlongley: Allowing this to work across DID methods could cause frustration and result in security problems. Both DID methods would need bidirectional links. User may confused if this works with DID A but not DID B. It may be very complicated or not even possible.
17:43:29 <drummond> I agree with Dave that these equivalence properties must be restricted to the same DID method. The proposed spec text already does that.
17:43:43 <markus_sabadello> dlongley: The values need to be within the same DID method. You cannot go cross DID methods.
17:43:46 <brent> ack dbuc
17:43:54 <markus_sabadello> dbuc: I don't think anyone is suggesting cross-method.
17:43:56 <dlongley> +1 to make it explicit in the spec
17:44:32 <markus_sabadello> dbuc: I don't see why we can't say "true" in the metadata. If you don't see it there, you don't use the property. It means the consumer looks in the metadata, if it's not there you don't use it.
17:44:47 <markus_sabadello> dbuc: I don't think we get the same force of this if it's in the metadata.
17:45:15 <brent> q?
17:45:20 <manu> q+
17:45:22 <markus_sabadello> dbuc: What about the boolean value wouldn't work?
17:45:28 <markus_sabadello> dmitriz: What do you mean by true boolean.
17:46:34 <markus_sabadello> dbuc: I mean e.g. in did:web, the resolver is going to wrap up what it gets from an endpoint, it will be wrapped in a resolution object. If the DID document is breaking the rules, then the did:web driver will not insert the property in the metadata. If that flag is not explicitly set to true, you don't use the property.
17:47:04 <manu> ack manu
17:47:05 <TallTed> can we not simply say that "DID-a sameAs DID-b" in DID-a's doc must be echoed by "DID-b sameAs DID-a" in DID-b's doc for that assertion to be accepted? If DID-b is not resolvable/dereferenceable/interpretable by DID-a's RP, then the sameAs is rejected for this interaction. (regardless of the sameAs/sameDid/equivalentId bikeshed result)
17:47:22 <markus_sabadello> dbuc: dmitriz does this clarify?
17:47:58 <markus_sabadello> dmitriz: You say, in addition to defining this sameAs/equivalentId property, we also add a resolution metadata field that says if this method supports the property.
17:48:00 <manu> That's what I'm trying to get dbuc to agree to TallTed ... but the conversation isn't going there :)
17:48:04 <manu> q+
17:48:15 <brent> ack manu
17:48:38 <markus_sabadello> manu: dbuc that additional "true" property requires two properties to do what a single property can do.
17:49:01 <markus_sabadello> +1
17:49:11 <markus_sabadello> manu: I think if we just express this in metadata, we're doing. There is no security problem, it solves the issue.
17:49:17 <dbuc> Manu: will you code your systems to look at all the methods' metadata and adhere to this extensions?
17:49:19 <markus_sabadello> s/doing/done/
17:49:25 <brent> PROPOSAL: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id.
17:49:36 <ivan> +1
17:49:37 <dbuc> +1
17:49:41 <Orie> +1
17:49:43 <dlongley> +1
17:49:44 <drummond> +1
17:49:47 <manu> +1
17:49:53 <markus_sabadello> drummond: That is what the PR says today.
17:50:01 <dmitriz> +1
17:50:39 <markus_sabadello> dbuc: The bidirectionality will not always be possible in the long term. For methods with an initiating payload, they may point to another DID, but the initial payload may be pruned away and not be available later.
17:50:44 <jonathan_holt> +0.5,  seems reasonable, but there may be cross interop between compatible DID methods
17:50:49 <brent> RESOLVED: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id.
17:50:58 <dlongley> drummond, please point to the text where it's already there
17:51:06 <dbuc> Some people are designing scalable methods that are also decentralized
17:51:09 <dlongley> https://github.com/w3c/did-core/pull/431/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R1377-R1378 <-- that does not say it
17:51:27 <markus_sabadello> ivan: It's the third item in the PR text
17:51:31 <dbuc> if you don't do that, you don't have any of these issues - centralization has its advantages
17:51:53 <markus_sabadello> dlongley: To me this doesn't mean that the DID itself uses the same method, it only says it's produced by that method.
17:52:19 <markus_sabadello> drummond: I never contemplated that a DID method could produce something for another method.
17:52:20 <manu> dbuc -- yes, and the people designing scalable methods that are also decentralized are telling you that there is a security vulnerability here :)
17:52:37 <Orie> nvm
17:52:39 <Orie> proceed
17:52:45 <dbuc> I 100% guarantee those are not decentralized to the same degree
17:52:50 <dbuc> else they would face all of this
17:53:00 <dbuc> this is a litmus test for decentralization
17:53:05 <drummond> +1
17:53:06 <dbuc> +1
17:53:08 <dmitriz> +1
17:53:18 <markus_sabadello> dbuc: Let's bikeshed the name
17:53:47 <markus_sabadello> manu: I think we should propose both properties. equivalentId and preferredId (or canonicalId)
17:54:08 <markus_sabadello> brent: Any suggestions for a better proposal?
17:54:15 <dbuc> "equivalentId" and "cannonicalId"
17:54:23 <dlongley> `canonicalId` is the proper spelling :)
17:54:38 <dbuc> +1 to spelled properly
17:54:44 <markus_sabadello> brent: Other suggestions?
17:54:49 <drummond> +1 to spelled properly
17:55:35 <dbuc> LOL
17:55:38 <dbuc> ORIE!
17:55:48 <markus_sabadello> ivan: Have a lower case l and capital I next to each other can make them indistinguishable
17:56:06 <brent> PROPOSAL: The two properties we are defining for equivalence are: equivalentId and canonicalId.
17:56:11 <Orie> +1
17:56:11 <drummond> +1
17:56:11 <manu> +1
17:56:12 <dlongley> +1
17:56:14 <dbuc> +1
17:56:18 <dmitriz> +1
17:56:21 <ivan> +1
17:56:26 <markus_sabadello> +1
17:56:31 <dbuc> canonical_id <-- a boy can dream, amirite, Orie?
17:56:46 <brent> RESOLVED: The two properties we are defining for equivalence are: equivalentId and canonicalId.
17:56:54 <jonathan_holt> + float
17:57:30 <markus_sabadello> manu: Will this be a DID document property, or metadata?
17:57:40 <markus_sabadello> dbuc: Can this be a required metadata property?
17:57:56 <markus_sabadello> manu: Yes it can be in the metadata section in the spec
17:58:06 <markus_sabadello> manu: Or it can go into the registry rather than DID Core spec
17:58:46 <markus_sabadello> dmitriz: Any developer has to read DID Core, DID Resolution, and DID method spec
17:59:22 <markus_sabadello> dbuc: If we can put it into the metadata section, next to contentType, it is required for implementers?
17:59:23 <markus_sabadello> manu: yes
17:59:33 <dbuc> I can get on board with that, I think
17:59:40 <dbuc> Drummond, what do you think?
17:59:47 <markus_sabadello> q+
18:00:15 <markus_sabadello> manu: If it's moved into metadata, we still need to agree how it's processed
18:00:20 <markus_sabadello> ivan: In the current PR, it's part of the core properties
18:00:41 <markus_sabadello> This should be DID document metadata rather than DID resolution metadata.
18:00:58 <dbuc> thank you!
18:01:02 <dlongley> if it's in the meta data it can also be produced by the DID method and returned by a resolver w/o changing the DID Doc (especially if the DID Doc is signed by some methods)
18:01:03 <dbuc> I am a pill, I know
18:01:16 <markus_sabadello> brent: Thanks all for coming. Next week we will meet for the regular call but no special topic call because of Thanksgiving.
18:01:26 <ivan> zakim, end meeting
18:01:26 <Zakim> As of this point the attendees have been dbuc, dlongley, markus_sabadello, brent, manu, rhiaro, ivan, jonathan_holt, TallTed, drummond, dmitriz, burn, selfissued, float
18:01:29 <Zakim> RRSAgent, please draft minutes
18:01:29 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/19-did-topic-minutes.html Zakim
18:01:31 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:01:36 <Zakim> Zakim has left #did-topic
18:02:37 <ivan> rrsagent, bye
18:02:37 <RRSAgent> I see no action items