DID WG Topic Call on Equivalence Properties — Minutes

Date: 2020-11-19

See also the Agenda and the IRC Log

Attendees

Present: Daniel Buchner, Dave Longley, Markus Sabadello, Brent Zundel, Manu Sporny, Amy Guy, Ivan Herman, Jonathan Holt, Ted Thibodeau Jr., Drummond Reed, Dmitri Zagidulin, Daniel Burnett, Michael Jones

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Markus Sabadello, Amy Guy

Content:

Brent Zundel: Make sure you present+ yourself

1. Equivalence properties

Brent Zundel: PR: https://github.com/w3c/did-core/pull/431

Brent Zundel: If noone is opposed, dbuc can walk us through the current status of this

Daniel Buchner: We have a PR out for 2 properties that bring the level of trusted equivalence for a variety of needs
… I had a presentation at TPAC

Brent Zundel: If you can walk people through the PR, that would be helpful

Daniel Buchner: The first property is “sameAs”.. A DID method can define different forms of a DID that are logically equivalent.
… One example is if the DID changes before registration and after registration
… In this case, the DID method may specify multiple DIDs that are logically equivalent

Daniel Buchner: Each sameAs DID must be within the same method
… DID method must guarantee that DIDs are logically equivalent
… A relying party must retain the DIDs, e.g. in a database

Ivan Herman: I would prefer not to use the “sameAs” term. Either this is owl:sameAs and you say it, or it’s something different
… The current text in the PR does more harm than good, it doesn’t make sense to create such problems

Daniel Buchner: I agree

Dmitri Zagidulin: +1 to what Ivan said.

Manu Sporny: I have 2 questions..

Orie Steele: +1 to ivan as well

Daniel Buchner: +1 to Ivan

Drummond Reed: So what should we use? equivalentID?

Daniel Buchner: Well, not exactly

Manu Sporny: I agree with ivan this is owl:sameAs, I think everyone agrees
… I’m concerned about this being expressed as a property in the DID document as opposed to DID resolver/document metadata
… This is asserted by the DID method, not DID subject or controller
… 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

Dmitri Zagidulin: +1 to manu’s point (that sameAs belongs in metadata not in the did doc itself)

Manu Sporny: It may be impossible to do this in did:web, since the DID method cannot assert this, only the controller

Daniel Buchner: DID Web still requires a resolution step

Daniel Buchner: which is where this would be excluded

Manu Sporny: I understand the use case, I think it’s very dangerous as a property, but can work as metadata expressed purely by the DID method

Dave Longley: 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
… 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
… There may be a simpler alternative.. The additional information can be expressed as VCs during an initial information.

Daniel Buchner: That’s asking for handoff failures and all sorts of other protocol juggling

Daniel Buchner: and I have to recreate that across all forms of transport handoffs

Manu Sporny: dbuc, you just need to implement Verifiable Credentials…

Manu Sporny: (which you’re going to do anyway)

Daniel Buchner: No, don’t need to ‘just implement VCs’

Daniel Buchner: you need whole protocols for what they mean across all the envelopes

Daniel Buchner: like OIDC, DID Comms

Manu Sporny: dbuc, no, you don’t need to do that.

Orie Steele: I think dlongley is responding the second property regarding the applicability of VCs
… Regarding the first property, this is about equivalent identifiers..
… Any DID method could construct RDF triples that are bad, you are 100% trusting the DID method
… Regarding did:web, there is acknowledgement that the DID controller has more authority

Orie Steele: 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

Drummond Reed: I agree with Orie. It actually feels more dangerous to trust something outside the DID document for a sameAs equivalence assertion.

Orie Steele: 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

Daniel Buchner: “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.
… If done with VCs it has no force. We want people to rely on it consistently.

Dave Longley: 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.

Jonathan Holt: owl:sameAs implies that the type = individual

Daniel Buchner: I don’t think it needs to be Owl sameAs

Manu Sporny: owl:sameAs does not imply that the thing is a person.

Drummond Reed: Correct.

Jonathan Holt: I can imagine a bank created a DID for me and aggregates my other identities that I wanted to be pseudo/anonymous.
… There may be security vulnerabilities, but also ethical dilemmas in the implementation.

Manu Sporny: 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.

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”.”

Manu Sporny: 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.

Jonathan Holt: individual = type person

Daniel Buchner: 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

Amy Guy: jonathan_holt: I think that use of ‘individual’ is referring to any single entity, rather than individual as in person

Manu Sporny: 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

Brent Zundel: q

Drummond Reed: To jonathan_holt, sameAs has nothing to do with being a person. It is just a statement of equivalence.

Manu Sporny: dbuc, the difference here is that this property doesn’t talk about YOU, it talks about someone/something else.

Drummond Reed: 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.
… 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.
… While working with dbuc on the initial text, when looking the attacks, we realized that DID methods either support this property or not.
… You can blocklist any DID methods that don’t support these properties correctly.

Daniel Buchner: Just put a metadata field in that says you support the prop

Daniel Buchner: so it requires an explicit TRUE in there to be relied upon

Drummond Reed: Communicating this information through another channel also introduces security risks, that you don’t have if it’s in a DID document.

Brent Zundel: this highlights how important DID Method security is

Dmitri Zagidulin: I wanted to challenge the claim that sameAs belongs in DID Core and the DID document.
… From everything that has been said so far, the meaning of sameAs is drastically different for each DID method.
… 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.

Daniel Buchner: The property language does unify it

Daniel Buchner: they must use it the way it is specified

Michael Jones: 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.

Markus Sabadello: back then 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
… eg. the created property
… that could sometimes be asserted by the controller but sometimes by the DID method
… 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
… 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
… it depends on the DID method
… talked about.

Daniel Buchner: 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.
… You could put a boolean value in the metadata to say if you are going to use it.
… As a method, you can say that you are affirmatively using this.

Orie Steele: whats more likely to be exploited: prototype pollution via proto or owl:sameAs via semantic logical processors?

Orie Steele: the ADM will preserve both.

Orie Steele: alsoKnownAs talks about another entity.

Dave Longley: +1 there’s a difference in “isolation” … is it about the DID Doc/DID subject or something outside of it

Manu Sporny: 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.

Daniel Buchner: That’s the entire point of equivalence

Orie Steele: service endpoints describe other entities

Manu Sporny: controller is the only thing that’s close to sameAs, but that is cryptographically authenticated

Drummond Reed: “controller” absolutely talks about another entity

Manu Sporny: 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

Dave Longley: drummond, asserting someone else can act on your behalf is different from saying you can act on their behalf

Dave Longley: wrt “controller”

Manu Sporny: 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.

Drummond Reed: I’m not saying there’s not a security issue, I’m just saying we can address it.

Brent Zundel: My proposal is that we actively work toward a solution that’s acceptable for everyone

Orie Steele: 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

Daniel Buchner: With regard to plugging the security problems. What would putting an affirmative “true” boolean in the metadata not cover?

Manu Sporny: We should explore it, but I think it’s a hack, I think moving the sameAs in the metadata would be safer.

Dave Longley: 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.

Daniel Buchner: If you’re telling me I can put something in the metadata that all MUST adhere to it?

Ivan Herman: 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?

Dave Longley: when you talk about “making RPs” do something

Drummond Reed: Yes that’s correct

Daniel Buchner: Can we not get caught up on the name?

Ivan Herman: If this is owl:sameAs, then you cannot make such a restriction. Value could be any IRI.
… You cannot put a restriction on something that’s already defined and used out there.

Daniel Buchner: Change it to sameBananaOctupusAs

Dave Longley: dbuc, yes, that would be great, there are two concepts

Drummond Reed: Then we should change the name to equivalentID

Daniel Buchner: it makes it less reliable outside

Daniel Buchner: not always possible to do that

Drummond Reed: I think ivan has a good point; we can give the property a different name. E.g. equivalentId or other name that works.
… I don’t think the security vulnerability is any different if you put it in metadata instead of DID document.
… One option is the resolver verifies the DID method supports equivalence properties or not. The other option is bidirectional resolution.
… If the property is present, the resolver can resolve the equivalent ID to verify they are cross-referenced. I think we should discuss this.

Dave Longley: 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.

Daniel Buchner: They both impose something. The RP must retain the equivalent identifier.
… 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.
… If this is not strongly specified, it won’t be reliable.
… 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.
… 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.

Orie Steele: 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.
… 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.

Dmitri Zagidulin: I don’t get the base-encoding arguments. Doesn’t multibase take care of this?

Orie Steele: 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.

Daniel Buchner: “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

Daniel Buchner: It’s not going to have the same effect

Orie Steele: One example is @context, the DID controller can often not control this, the DID method does.

Orie Steele: implementation of did methods is out of scope for this WG

Orie Steele: ^^ chairs?

Manu Sporny: 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.
… I suggest alternative names: equivalentDidMethodId and preferredDidMethodId
… 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
… If we move this into metadata, and make sure only the DID method can assert this, then I may agree with this.

Dave Longley: I think we’re missing a requirement 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.
… 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.

Drummond Reed: I agree with Dave that these equivalence properties must be restricted to the same DID method. The proposed spec text already does that.

Dave Longley: The values need to be within the same DID method. You cannot go cross DID methods.

Daniel Buchner: I don’t think anyone is suggesting cross-method.

Dave Longley: +1 to make it explicit in the spec

Daniel Buchner: 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.
… I don’t think we get the same force of this if it’s in the metadata.
… What about the boolean value wouldn’t work?

Dmitri Zagidulin: What do you mean by true boolean.

Daniel Buchner: 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.

Ted Thibodeau Jr.: 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)

Daniel Buchner: dmitriz does this clarify?

Dmitri Zagidulin: 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.

Manu Sporny: That’s what I’m trying to get dbuc to agree to TallTed … but the conversation isn’t going there :)

Manu Sporny: dbuc that additional “true” property requires two properties to do what a single property can do.

Markus Sabadello: +1

Manu Sporny: I think if we just express this in metadata, we’re done. There is no security problem, it solves the issue.

Daniel Buchner: Manu: will you code your systems to look at all the methods’ metadata and adhere to this extensions?

Proposed resolution: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id. (Brent Zundel)

Ivan Herman: +1

Daniel Buchner: +1

Orie Steele: +1

Dave Longley: +1

Drummond Reed: +1

Manu Sporny: +1

Drummond Reed: That is what the PR says today.

Dmitri Zagidulin: +1

Daniel Buchner: 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.

Jonathan Holt: +0.5, seems reasonable, but there may be cross interop between compatible DID methods

Resolution #1: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id.

Dave Longley: drummond, please point to the text where it’s already there

Dave Longley: https://github.com/w3c/did-core/pull/431/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R1377-R1378 <– that does not say it

Ivan Herman: It’s the third item in the PR text

Dave Longley: To me this doesn’t mean that the DID itself uses the same method, it only says it’s produced by that method.

Drummond Reed: I never contemplated that a DID method could produce something for another method.

Daniel Buchner: Some people are designing scalable methods that are also decentralized

Daniel Buchner: if you don’t do that, you don’t have any of these issues - centralization has its advantages

Manu Sporny: dbuc – yes, and the people designing scalable methods that are also decentralized are telling you that there is a security vulnerability here :)

Daniel Buchner: I 100% guarantee those are not decentralized to the same degree

Daniel Buchner: else they would face all of this

Daniel Buchner: this is a litmus test for decentralization

Drummond Reed: +1

Daniel Buchner: +1

Dmitri Zagidulin: +1

Daniel Buchner: Let’s bikeshed the name

Manu Sporny: I think we should propose both properties. equivalentId and preferredId (or canonicalId)

Brent Zundel: Any suggestions for a better proposal?

Daniel Buchner: “equivalentId” and “cannonicalId”

Dave Longley: canonicalId is the proper spelling :)

Daniel Buchner: +1 to spelled properly

Brent Zundel: Other suggestions?

Drummond Reed: +1 to spelled properly

Ivan Herman: Have a lower case l and capital I next to each other can make them indistinguishable

Proposed resolution: The two properties we are defining for equivalence are: equivalentId and canonicalId. (Brent Zundel)

Orie Steele: +1

Drummond Reed: +1

Manu Sporny: +1

Dave Longley: +1

Daniel Buchner: +1

Dmitri Zagidulin: +1

Ivan Herman: +1

Markus Sabadello: +1

Resolution #2: The two properties we are defining for equivalence are: equivalentId and canonicalId.

Jonathan Holt: + float

Manu Sporny: Will this be a DID document property, or metadata?

Daniel Buchner: Can this be a required metadata property?

Manu Sporny: Yes it can be in the metadata section in the spec
… Or it can go into the registry rather than DID Core spec

Dmitri Zagidulin: Any developer has to read DID Core, DID Resolution, and DID method spec

Daniel Buchner: If we can put it into the metadata section, next to contentType, it is required for implementers?

Manu Sporny: yes

Daniel Buchner: I can get on board with that, I think

Daniel Buchner: Drummond, what do you think?

Manu Sporny: If it’s moved into metadata, we still need to agree how it’s processed

Ivan Herman: In the current PR, it’s part of the core properties

Markus Sabadello: This should be DID document metadata rather than DID resolution metadata.

Daniel Buchner: thank you!

Dave Longley: 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)

Daniel Buchner: I am a pill, I know

Brent Zundel: Thanks all for coming. Next week we will meet for the regular call but no special topic call because of Thanksgiving.

2. Resolutions