How to actually identify the DID subject?

[RieksJ]

According to the spec, the party that controls a DID gets to determine the entity that this DID identifies (i.e.: the DID subject). However, that would only be useful if others could find out (under appropriate conditions) what the entity is that a DID identifies. Currently, there is no guidance for parties that want to do this. One thing is certain: the entity that is identified by the DID does not necessarily control that DID (as some seem to assume).

To make this practical: suppose Alice has created did:example:frontdoorcamera, which she wants to use as identifier for the camera that she is actually using to guard her front door. She has also created did:example:cam2 that she uses as an identifier for a (different) IP-camera that she recently bought. Alice controls both DIDs (the camera's do not).

Now the front door camera breaks down, and Alice tells Bob that he needs to come over rand repair the entity that she identifies as did:example:frontdoorcamera. How does Bob know what entity to repair?

Since Bob can't do anything, Alice replaces the frontdoor camera with the IP-camera she recently bought. How does that change the DID docs of did:example:frontdoorcamera and did:example:cam2?

Does it make sense to provide some actual guidance on these matters?

[OR13]

https://www.w3.org/TR/did-core/#example-a-simple-did-document

https://v.jsld.org/2sbs58oPvQc1ED2bp5sxUpAmC3UZ3HH445jZkVX9V8UzDo1zVyccs9CQC46aa4umzk2ghYK8t9xVvW4jJdo6Ac2hj48yyrk2gbRvY2tg7FFagji7DzL5kdj68KQE7kJ3QJzekm7sXmnwncGHuuK3heZWPwZhLEkSSMgYeYAxKZccQv3BS1Vs9waJJoB83QmYud93REbhxyM53X8T9cY2uuHfvtr3ZDVfhZyp3jbD2gE6pUGSiEY2HPTXMnF7AEn582gS6GJ5GbZQuqYWSx36Ay5zEdQ9J3uguSFzTHN1JixiZbduUT53BGjvragcE3JL52dRoTuRRUJNsqLW1Z57B9KrpiwWkuhTT

<did:example:123456789abcdefghi#keys-1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519VerificationKey2020> .
<did:example:123456789abcdefghi#keys-1> <https://w3id.org/security#controller> <did:example:123456789abcdefghi> .
<did:example:123456789abcdefghi#keys-1> <https://w3id.org/security#publicKeyMultibase> "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"^^<https://w3id.org/security#multibase> .
<did:example:123456789abcdefghi> <https://w3id.org/security#authenticationMethod> <did:example:123456789abcdefghi#keys-1> .

<did:example:123456789abcdefghi> is the subject.

• https://www.w3.org/TR/json-ld11/
• https://www.w3.org/TR/rdf11-concepts/#dfn-subject

• https://www.w3.org/TR/did-core/#did-subject

How a DID Controller, who is also a DID Subject, creates new DIDs, is use case specific, I don't know what text we might add to clarify this, but you are welcome to propose text you think would be helpful on this issue.

[dlongley]

I would think the kind of guidance we could offer would be like: "Alice can include one or more Verifiable Credentials that express information (such as location, etc.) about the subject (the front door camera) using its DID as the credentialSubject identifier of the VCs".

She could also simply, in the same message where she says "the DID is did:example:frontdoorcamera", say that it's the front door camera. That's how it would normally work, right? Or it could be the case that each camera can be queried for its DID and Bob could just ask each one (perhaps less optimal, but possible). Any number of these things seem like they could be solutions -- but like Orie said, it is use case specific. So maybe this kind of thing could just go into a use case or examples document to help people understand some options.

[TallTed]

I would think there would be a description document somewhere, of the entities identified as did:example:frontdoorcamera and did:example:cam2, which might include serialNumber, vendor, model, and any number of other attributes which would enable Bob to differentiate between did:example:cam2 and did:example:frontdoorcamera when trying to figure out which is the one in need of repair.

[RieksJ]

@OR13 wrote:

* https://www.w3.org/TR/did-core/#did-subject

I would say that a node in a linked data graph is a representation of some entity that may or may not have an identifier to go with it (such as a DID). I would call that entity the subject (of that identifier); if the identifier were lacking, then the semantics of a node is that a (further unidentifiable) entity exists (that is related to the various objects through the respective properties).

The current DID spec is in line with that (my guess is that your picture is obsoleted) - see https://www.w3.org/TR/did-core/#dfn-did-subjects):

[RieksJ]

@dlongley @TallTed So if we focus on a VC (and a description document could very well take that form), then the DID would be the subject identifier of one (or more) claims in a VC, and documenting the serial number, brand etc., would enable Bob to identify the cameras. While this is true for this specific case, there is currently no general way in which to identify the DID subject if the DID is used in a VC claim.

Do you think it would be beneficial to define some structure for VCs that mentions a DID, specifies a set of attributes/characteristics and a method by which such attributes may be used to verify whether or not some entity is the subject of that DID, e.g.:

idmeans: [ {
    id: "did:example:frontdoorcamera",
    type: "manual-check",
    serialnumber: 12345678,
    type: "MXF-4",
    manufacturer: "CamFab, Inc.",
} ],

You could then also have idmeans-sections that enable Bob to remotely connect an endpoint and enable him to identify (and authenticate) the equipment at that endpoint as the DID subject (i.e.: the frontdoor camera).

[dlongley]

@RieksJ,

I do think that's a useful construct, but also use-case dependent. I don't think this group should define it (I don't think that's what you meant though?) ... and maybe there's something common to be defined in the VCWG, but really, it seems like it's something that would be defined by a particular VC vocabulary. For example, I'd expect some camera / IoT / gadgets vocab to define something like idmeans for people to put into their VCs.

Perhaps there could be an example in a / the VC developer guide.

[RieksJ]

Sounds reasonable. For the DID spec, would it then be useful to add a paragraph stating that

• a DID controller needs to think about what means verifiers would need to identify/authenticate the DID subject,
• provision for (a selection of) such means (which is outside the scope of the DID spec), and
• warn that this is likely not going to be the same as proving control of the DID)?

[talltree]

Rieks, I agree that these points would be useful. I could see including in the next version of the spec a section called something like “Verifying the Real-World Subject Identified by a DID”. We’ll put this on the “to-do” list. Best, =Drummond From: Rieks ***@***.***> Date: Wednesday, November 23, 2022 at 11:14 PM To: w3c/did-core ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [w3c/did-core] How to actually identify the DID subject? (Issue #837) Sounds reasonable. For the DID spec, would it then be useful to add a paragraph stating that * a DID controller needs to think about what means verifiers would need to identify/authenticate the DID subject, * provision for (a selection of) such means (which is outside the scope of the DID spec), and * warn that this is likely not going to be the same as proving control of the DID)? — Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fdid-core%2Fissues%2F837%23issuecomment-1326045186&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C0ab7ac4b7ca84bfee7b608dacdeb894d%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638048708746953571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DeFdIF9IM9zmgJLOz27wRx5MQQoqNPL%2FSmKXTD6qT3w%3D&reserved=0>, or unsubscribe<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAZOITPPX37XECBRL2DEL63WJ4IVNANCNFSM6AAAAAASH6KPYI&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C0ab7ac4b7ca84bfee7b608dacdeb894d%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638048708746953571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HErCRl%2BssecS%2FCSdJLMykVyq9x%2FxKyxPqseJexY2Pew%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Neurone]

Isn't the DID document already enough for this use case?

DID document. A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.

If I understood correctly, the whole idea of Decentralized Identifiers is not for Bob being able to prove something but for the DID subject to prove its association with a DID, such that Bob can verify that association. The DID subject is an active actor, not a passive one.

If Alice wants to identify things, she can use UUIDs. But if she intends to let devices (subjects) identify themselves, she creates and distributes identities to those devices so that they can later prove their association with that identity.

So, in the case above, Alice creates the DIDs and distributes the keys needed to prove the association to the correct devices. Bob enters the house and broadcasts the message: "Who is did:example:frontdoorcamera?", and - if the system is not compromised ;) - only the DID Subject can respond with verifiable proof of its association with the correct DID. And Bob can repair that device.

[RieksJ]

@Neurone The DID spec disagrees with your statement that a DID subject is (always) an active actor. It says: "A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID". I agree with the DID spec, because it allows for DIDs to refer to things, e.g. containers (in logistics), and also know who controls them.

Even if the DID doc may be enough for this use case, the issue that I would like to be addressed is not use case specific. It leaves parties that get confronted with a DID clueless as to what entity it refers to. I think that this causes people to make lots of different assumptions, e.g. that the DID subject equals the party that controls the DID (which may be true in some cases, but would not be true in general), which can have unwanted, if not dangerous consequences.

[agropper]

It's complicated and it has a lot to do with market adoption: - It's academically attractive to treat DIDs as applying to people, things, and concepts but that causes huge adoption issues when faced with ISO/mDL that takes the human first approach - DIDs applied to things or concepts are still tied to a human some of the time - because it's in your house, for example - The protocols for dealing with people are, in practice, very different from those that deal with things. Avoiding the distinction at the root then causes huge harm or expense downstream. I use the example of alcohol which is a miracle industrial commodity and a huge societal burden. The cost of regulating this dual use technology is managed by introducing denatured alcohol as the industrial version so it can exist outside of the regulated human oriented commodity. - DIDs applied to things and concepts do not have the benefit of biometrics. When a thing (without biometrics) like a vaccination card does not have biometrics at the root it has to be used in conjunction with a biometric like a driver's license. There are work-arounds, of course, but by starting with the same DID and presuming the same protocols it's easy to add friction and cost to deployments. Adrian

…

On Fri, Dec 9, 2022 at 2:52 AM Rieks ***@***.***> wrote: @Neurone <https://github.com/Neurone> The DID spec disagrees with your statement that a DID subject is (always) an active actor. It says: "A DID <https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers> refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID <https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers>". I agree with the DID spec, because it allows for DIDs to refer to things, e.g. containers (in logistics), and also know who controls them. Even if the DID doc may be enough for this use case, the issue that I would like to be addressed is not use case specific. It leaves parties that get confronted with a DID clueless as to what entity it refers to. I think that this causes people to make lots of different assumptions, e.g. that the DID subject equals the party that controls the DID (which may be true in some cases, but would not be true in general), which can have unwanted, if not dangerous consequences. — Reply to this email directly, view it on GitHub <#837 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YJQMF5DNDNZVGNBKHLWMLQMXANCNFSM6AAAAAASH6KPYI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RieksJ]

@agropper I don't see how market adoption is going to complicate things, unless the market is doing things that contradict what the standard says. That would be a different issue.

DIDs applied to things or concepts are not still tied to a party, they have always been that. I contend that every party gets to autonomously decide to which entity (thing or otherwise) any of the identifiers that it uses refers. You may decide to have 'daddy' refer to another entity than I do. If you want to name your fridge 'localhost', then that's your call. Parties with any common sense will, of course, try to align the semantics of their identifiers (i.e. the entities to which it has decided to let them refer) with that of other parties, but it isn't a given: relying on that comes with a risk.

This controlling of one's identifier semantics is distinct (yet related) to the topic of how one can identify the entity to which an identifier (that is controlled by a given party) is actually referring.

Those that adopt DIDs should be aware of this difference. If they are not, they could well assume that the one that controls the DID is the entity to which the DID refers. Let's call her Alice. She asks Ivan to issue a VC that uses her DID as a subject identifier for the claim that she is 18+. Before doing this, Ivan makes sure Alice actually controls the DID (which she can prove), convincing himself that he just signed the claim "Alice is over 18". After having received that VC, Alice passes control of the DID to Chuck. That doesn't change the VC, which therefore can still be verified. So, Chuck can present it to Bob, which sees that verification succeeds. Then, when Bob asks Chuck to prove he controls the DID, Chuck can comply, the result of which is that Bob thinks that Ivan has signed the claim "Chuck is over 18".