Did-core: Clarification on what DIDs might identify

[brentzundel]

I think there is agreement in the group that DIDs may be used to identify entities such as people, agents, IoT devices, etc.
What about using DIDs to identify things that are incapable of interacting using cryptographic keys? What if there is no controller property or public keys at all? Could a DID document simply contain, or point to, some content?

Could the following have DIDs?:

• the moon
• a schema, context, or verifiable credential
• an item in a database
• insured assets

Apologies if this is a re-hash of an already concluded conversation. I searched but did not find.

[jandrieu]

There are two ideas here.

The first, yes, one should be able to use DIDs to identify subjects like the moon, e.t.c. which is especially useful for VCs.

However, using a DID document to publish information about the subject is an anti pattern i actively discourage. IMO, a DID document should only contain information needed for secure interactions with the subject. We can't prevent people adding assertions that the moon is made of cheese, but it's really a violation of the moon's privacy' so let's not encouraged that.

[iherman]

@jandrieu, just to clarify, though: while I agree that assertions about the details of the moon are an anti-pattern, it _is_ acceptable to add a reference (I guess as a service) to a home page on the Web authoritatively describing the subject. (I use the 'authoritatively' in a loose sense; e.g. is to refer to my personal Web site, for example.)

[dlongley]

I agree with @jandrieu.

@iherman,

just to clarify, though: while I agree that assertions about the details of the moon are an anti-pattern, it is acceptable to add a reference (I guess as a service) to a home page on the Web authoritatively describing the subject.

In principle, yes, but the same PII rules apply. In my view, I think which statements can/should be made about a DID subject in a DID Document largely depend on who can resolve the DID to get the DID Document -- and the nature of the system that stores these statements, including how it "forgets" such statements when desired. These two qualifiers could perhaps be summed up by saying "it depends on the DID method".

For example, Veres One intends to disallow PII of this sort to be stored on its ledger, instead preferring to use a privacy preserving "ProxyService" endpoint. The proxy service endpoint would be expressed in the DID Document returned when resolving the DID, but it would not reveal PII about the DID subject itself. The service could, however, be used to retrieve more statements about the DID subject in a way that supports deletion and, potentially, authorization. It is here that additional services that may contain PII such as what you mentioned (home page on the Web) would be expressed. Either way, all statements about the DID subject (whether retrieved from the DID Document or an extension of it via the ProxyService) can all be collapsed into a single graph of statements about the DID subject -- and then passed to an application for consumption.

[jandrieu]

Yes, you can have a service endpoint to get more information, but I believe that is a flawed approach.

We can't keep people from doing it without removing service endpoints, which I do not believe is a viable option at this stage.

However, turning DIDs into a lookup mechanism for details about subjects is a fundamental privacy problem. IMO, we don't need more directories that let anyone glean information, PII or otherwise. This information WILL be aggregated and it WILL be used improperly.

In my professional opinion, the DID subject should ALWAYS be in the loop for any disclosure of information. We have zero mechanisms on the table for purpose binding and consent in the DID Document and while you could place that functionality behind a service, it still lacks the human in the loop unless, again, you create an extraordinary service endpoint far beyond what most have been discussing. Far better for individuals to ALWAYS explicitly share whatever information they choose to (and not sharing what they don't), using the DID infrastructure to verify the veracity of that information and the proof of control for authenticating as the subject.

IMO, this is the proper best practice for protecting privacy, but I may well be a minority voice in this working group.

[brentzundel]

I agree that a DID document should not be used to look up personal details of DID subjects. This issue is more to explore 2 ideas:

1. Having DIDs for things that can't interact in any meaningful way using cryptographic keys, whose DID documents may not even contain public keys or controller information.
2. Having a DID document that contains the DID subject (or is the DID subject).

I'm wondering if it makes sense for the subject of a DID to be a JSON-LD context document; essentially using the did resolution process to retrieve some content that may or may not have any public keys or controller associated with it.

[jandrieu]

For #1, that seems like a weird edge case. I believe all of the methods use keys to control the DID Document, which means that there ARE keys associated with the DID, whether they are in the document or not. I can create a DID for the moon and start issuing VCs either about the moon or "from" the moon. That's an interesting bit of fiction... and I look forward to the artist who takes up that task. What can never be known definitively is whether or not the controller of those keys is, IN FACT, the moon. IMO, any attempt to restrict this will be untenable. The only real option is to understand that the Subject isn't necessarily the Controller, and as such, what the Controller does may or may not legitimately represent the actions of the subject. DIDs can only ever be a single factor in what will need to be a multi-factor tapestry of identity proofing and authentication.

For 2, we have two things. If the DID Document is its own subject, we have a recursive problem similar to http range 14. What I think we probably need is the ability to specify in a DID-URL that we are referring to the DID Document instead of the DID Subject. Then you can make VCs with the DID Document URL as a distinct thing from VCs about the DID Subject (which uses the naked DID). However, I don't believe it makes sense to be self-referential in regards to the subject. Is there a use case that you can describe for this?

The second have of #2 is if the DID Document contains the DID Subject. That's also a bit weird. I think the same work-around as above would be appropriate, but I would need to understand the use case. Do you mean that a specific property (or set of properties) in the DID Document is somehow the Subject referred to by the DID? I'm struggling with out a concrete example, but I think the same DID-URL approach used for the entire document should work for part of the document, IF the scope of the Subject is describbale within the DID-URL syntax. For example, I don't currently see how you could specify multiple distinct properties within a DID Document in a single DID-URL.

Use cases would help.

[dlongley]

@jandrieu,

Yes, you can have a service endpoint to get more information, but I believe that is a flawed approach.

I think we're miscommunicating.

A "home page", "personal website", or "personal VC service" may contain PII in the URLs themselves. They are also "mechanisms for interacting securely with the DID subject". With the approach I outlined, DID methods that use DLT/blockchain tech can have a mechanism for discovering those service URLs (which can then be used to get access to more information with the appropriate consent, etc.) without running afoul of "the right to be forgotten" -- because the URLs themselves are not on the blockchain. Instead, a non-PII ProxyService that is on the blockchain enables you to get them from a non-blockchain service. I think this is an important and useful feature. I am not suggesting that the feature be abused to express your SSN.

[jandrieu]

I understand the work-around. I still think it's the wrong approach. Using a DID registry as a white pages is going to cause harm. Full stop. I'm not talking about regulatory compliance, I'm talking about the structure of available information.

Yes, people will still do it.

Yes, people will get value out of giving out a DID URL that magically moves from service to service as their life evolves.

Just like we get value out of having a public posting board at the local coffeeshop where businesses can post flyers. And who would blame individuals for wanting the same convenience?

Sacrificing your privacy for convenience happens all the time. Heck, my address has been publicly linked to my name and companies my entire adult life. I get it.

Doesn't mean I'm going to recommend it to my loved ones or clients. Nor do I think we should stop seeking an system that enables secure interactions without inviting wholesale loss of privacy.

Creating a large scale identity architecture that invites all participants to publicly link service URLs and related information to a known identifier will create a medium for exploitation. And it will be exploited.

It behooves us to find better options.

[talltree]

This thread has moved quickly. I want to go back to @brentzundel 's original question:

What about using DIDs to identify things that are incapable of interacting using cryptographic keys?

My answer is absolutely yes. This has been assumed about DIDs since the very first version of this spec four years ago. In short, a DID can be use to identify "anything with identity". Period.

I started the following simple diagram during our F2F meeting in Amsterdam last month:

IMHO, this captures everything that needs to be said about the relationship of a DID Controller, a DID Subject, and a DID Document:

• A DID can identify anything with identity (i.e., anything can be a DID Subject).
• The DID Controller determines what is identified by the DID (i.e., the DID Subject).
• The DID Controller determines how the DID Subject is described by the DID Document.

So the fact that a DID identifies a DID Subject that is not capable of interacting using cryptographic keys is immaterial for several reasons:

1. The DID Subject may be an inanimate object (say, a teapot), but it can still be represented by a digital agent that is capable of interacting and using cryptographic keys on behalf of that inanimate object (for example, an agent for the teapot that is able to provide product information, verifiable credentials about proof-of-origin, warranty service, etc.).
2. The DID Subject may need to be identified by the DID Controller only for reference purposes and not offer any means of interaction. In this case the only purpose of cryptographic keys in the DID Document would be for the DID Controller to control updating of the DID Document.
3. The DID Subject may need to be identified by the DID Controller for reference purposes only and have a static description that never needs to change. In this case the DID Document never needs to have any cryptographic keys at all.

All of the above (and others I've probably missed) are possible, which is why everything is optional in a DID Document except the DID (because without a DID, you're not identifying anything at all).

ADDENDUM No sooner did I finish this comment than what appeared in my email was a notification from W3C that Web of Things (WoT) Architecture is now W3C Proposed Recommendation. WoT is a perfect candidate for DIDs that identify things that may or may not have the ability to interact using cryptographic keys.

[brentzundel]

From Drummond's comment, number 3 is what I was looking for. I know that this is allowed by the spec (everything is optional except ID), but I wasn't sure how palatable such an idea would be.

For @jandrieu, an example of what a DID Doc might look like if it contained a JSON-LD @context as the DID Subject:

{
    "@context": [
        "https://www.w3.org/ns/did/v1", 
        "did:example:yfXPxeoBtpQABpBoyMuYYGx"
    ],
    "id": "DID:example:BmfFKwjEEA9W5xmSqwToBkrpYa3rGowtg5C54hepEVdA",
    "subject":{
        "rstype": "ctx",
        "name":"DriverLicense",
        "version":"1.0",
        "hash":{
            "type": "SHA2-256",
            "value": "a005abbfcfaf7b0d703a7fc9fb86c8b71a33a10ef24d292984fc863c225205b9"
        },
        "data":{
            "@context": [
                "did:example:UVj5w8DRzcmPVDpUMr4AZhJ",
                "did:example:JjmmTqGfgvCBnnPJRas6f8xT",
                "did:example:3FtTB4kzSyApkyJ6hEEtxNH4",
                {
                    "dct": "http://purl.org/dc/terms/",
                    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
                    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
                    "Driver": "did:example:2mCyzXhmGANoVg5TnsEyfV8",
                    "DriverLicense": "did:example:36PCT3Vj576gfSXmesDdAasc",
                    "CategoryOfVehicles": "DriverLicense:CategoryOfVehicles"
                } 
            ]
        }
    }
}

[talltree]

@brentzundel I'm curious about your "subject": property above. Is that a proposed generic DID document property for describing (vs. identifying) a DID Subject, or a crossover from Verifiable Credentials, or something you developed for this use case, or...?

[brentzundel]

It is something that was developed for this use case.
If a context document may be identified by a DID, then it might make sense
to allow it to be retrieved via a DID document.

On Thu, Feb 20, 2020, 20:42 Drummond Reed [e-mail] wrote:

@brentzundel https://github.com/brentzundel I'm curious about your
"subject": property above. Is that a proposed generic DID document
property for describing (vs. identifying) a DID Subject, or a crossover
from Verifiable Credentials, or something you developed for this use case,
or...?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/199?email_source=notifications&email_token=ACPFKPZTVRFVW3JEYCIK5S3RD5EQPA5CNFSM4KXMHSZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMRM6EY#issuecomment-589483795,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPFKP7DRUAMCF2BUFVWLQTRD5EQPANCNFSM4KXMHSZQ
.

[talltree]

@brentzundel That makes sense to me. In fact it was @dlongley who originally convinced me that not only could a DID identify anything, but a DID document could describe anything. Originally I had thought that the DID document would just include a service endpoint from which you could get a description of a DID Subject. And that certainly can make sense if the description needs to be access-controlled in some way.

But if the description is itself public information resource (like a schema or a JSON-LD context or a verifiable credential definition), then why not save a round-trip (and the extra protocol switching) and just have the DID Subject be contained within the DID document itself?

What I like about the "subject": property is that we could, in fact, make this a standard generic DID document property for any DID Subject that is an information resource contained in the DID document itself. A "type": subproperty could define the type of this information resource (in your example you use "rstype":, but we could generalize that). And "data": could be the body property that contains the actual information resource, precisely as you show in your example.

Lastly, it would be trivial for a DID resolver to be asked to return any DID Subject that was an information resource contained in a DID document using this approach.

[ken-ebert]

This solves the problem that I have been working on at Sovrin for over a year: how to identify immutable resources such as contexts, schemas, credential definitions, etc. in a way that is compatible with the DID resolution process. Matrix parameters were first suggested as a way to solve this problem; matrix parameters come with their own baggage. Using a DID to identify the digital resources and returning the resource within the DID document elegantly solves my use case.

[talltree]

@ken-ebert That's exactly what I was thinking when I first saw Brent's example. As you recall, Ken, you and I spent an entire Rebooting the Web of Trust conference in Barcelona a year ago working on how to best solve the problem of using DIDs to address immutable content. In retrospect I'm not sure why we didn't see this solution—it strikes me now as one of those "blinding flashes of the obvious".

[jandrieu]

@ken-ebert I don't think it solves that problem, because the DID Document is not itself immutable. You could refer to a context with a DID and then update the DID Document to contain different data.

[jandrieu]

@ken-ebert I think the better way to handle this is just a service endpoint with a data: url. rather than data at the top level. So users can say did:example:123;avatar and get back the png given as an avatar because the service endpoint is defined as in this gist: https://gist.github.com/jandrieu/34c5b05cef5b01f80b9088b339de9798

Of course, you would use the actual context instead of a picture of me.

This is a more generalizable approach to get what you want: storing context in the did document, without inventing anything new. Data: urls have been around a long time.

A convention about what to name that service endpoint would be useful, but sticking a data property at the top level seems like putting an http resource in your DNS record. It's conflating two different parts of the layered architecture and may not work well with the other layers.

[talltree]

@jandrieu Let me respectively disagree. It's not that there's anything wrong with a data: URL. I'm a fan of them when appropriate. But in that case the bare DID would not actually identify the target information resource. Only the full DID URL with the addition of the service endpoint parameter would actually identify the target information resource. And there's still the open question of what you would call that particular service endpoint parameter.

What I understand Brent and Ken are after is that the DID identifies the target information resource itself and nothing else. So the target information resource IS the DID subject.

Putting the target information resource in the DID document as the body of the subject property seems like a very simple and elegant solution for this particular use case. No parameter and no other indirection is needed: it states clearly and unambiguously in the DID document that the DID subject is an information resource that is the body of the subject property.

This approach also takes advantage of the fact that no other separate data repository is needed for the information resource. In other words, since a DID method must already be responsible for long-term persistence of DID documents, then why not also use that same persistent storage mechanism for an information resource identified by a DID?

IMHO this gets to one of the key ways that DID architecture is different than DNS architecture. DID architecture is not only _decentralized_ instead of _federated_, but DID documents can be _self-describing_. What Brent and Ken are suggesting is one way to take advantage of that self-description: take an immutable information resource and wrap it in a DID document so it becomes permanently addressable via that DID.

[kdenhartog]

then why not also use that same persistent storage mechanism for an information resource identified by a DID

1. Managing scale: Handling data directly on ledger increases the storage requirements for a node to join the network. This was one of the main reasons bitcoin core opted to not increase blocksizes. Additionally, general-purpose storage changes the usage patterns of the ledger thereby increasing the storage requirements. This is one of the reasons the Ethereum ledger requires more data to run a full (non-pruned) node than a bitcoin core node.

2. Managing data types is made harder:
   If some use cases accept data to be stored on-ledger (e.g. DID of driver in @brentzundel example) whereas other use cases (e.g. putting my name in the driver) could introduce privacy and legality concerns. For the specific example I mentioned, this would require the ledger nodes to parse data being written to the to make sure privacy concerns aren't an issue. Alternatively, the TAA approach can be taken where the author asserts a legally binding contract when they author a transaction, but this solution would end up relying on some form of moderation (e.g. is this content actually a problem or not) which is inherently hard to scale globally.

[jandrieu]

@talltree I think the bigger issue is that the proposed addition changes the semantics of DIDs as URIs and URLs. You are essentially adding a default resource to return when a DID URL is dereferenced, which is something OTHER than the DID Document, depending on the presence of a special, optional property in the DID Document . Now you have two very different responses to dereferencing a DID, depending on the presence of a "data" element, but only if a service endpoint is also not defined, in which case, what happens remains TBD.

IMO,

1. resolving a DID should return the full DID Document
2. dereferencing a DID without a service part should return the full DID Document
3. dereferencing a DID with a service part should return the resource specified by the service endpoint in the DID Document

This proposal adds another level of complexity, despite the opportunity to achieve the same phenomenon with a service endpoint. In fact, if you don't like data: URLs, add a new type of service endpoint, perhaps "resource" which will return the specified property directly.

Messing with what it means to de-reference a DID Url seems like the wrong way to get what you want. It adds unnecessary complexity without adding features that can't already be achieved.

My strong advocacy here is that we should stop trying to do more with DID Documents by jamming new content into them. Rather, we should be minimizing what is in the DID Document to make interoperability more achievable. More is less and less is more.

[iherman]

You are essentially adding a default resource to return when a DID URL is dereferenced, which is something OTHER than the DID Document, depending on the presence of a special, optional property in the DID Document . Now you have two very different responses to dereferencing a DID, depending on the presence of a "data" element, but only if a service endpoint is also not defined, in which case, what happens remains TBD.

I guess this is related to the separate issue which has been bugging me since the face-to-face, see https://github.com/w3c/did-core/issues/183, in particular https://github.com/w3c/did-core/issues/183#issuecomment-587018974 ...

[peacekeeper]

@jandrieu

1. dereferencing a DID with a service part should return the resource specified by the service endpoint in the DID Document

This is almost correct. In fact, dereferencing a DID URL with a service part (service matrix parameter) does not return the resource at the service endpoint. Instead it returns the service endpoint URL, and then a second dereferencing process is executed on that URL.

This is comparable to how HTTP redirects work. The browser tries to dereference the first URL, but it gets another URL instead of a representation of a resource. It then dereferences that second URL.

See https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm for more details.

[Oskar-van-Deventer]

What is the relationship between the discussion in the present issue #199 and #190?

[Oskar-van-Deventer]

I took the liberty of making a pull request to clarify what a DID identifies, see #213.

"A DID identifies an entity that is capable of creating digital signatures, e.g. a natural person, a legal entity or an autonomous machine."

Would this help this discussion about "Clarification on what DIDs might identify"?

[brentzundel]

I've made comments in the PR and do not feel that it addresses this issue.
There's nothing in the spec that prevents someone from having a DID Doc like the one here, so I'm not looking for any spec changes, but I would like more feedback on the idea.
Perhaps @dlongley, @msporny, @dmitrizagidulin, @SmithSamuelM or @selfissued could chime in?

[pknowl]

@talltree Thanks for bringing this discussion to my attention. I'm sure @ken-ebert and @brentzundel would have brought it up in the next HL Semantics WG call for in-depth discussion. I'll put it down as an agenda item for the next Semantics call.

[talltree]

Thanks @pknowl. I agree that persistent and verifiable identification of semantic resources is hugely important for the entire world of trusted interactions—which is why I thought this thread had great potential. I don't know if I can attend the next HL Semantics WG call, but please send me a reminder if you can and I will do my best. I strongly urge @brentzundel, @ken-ebert, and @dhh1128 to come too.

[kdenhartog]

Was there any consensus on this during that call? I figured out when I mulled over this a bit more that my biggest issue is with the fact that in @brentzundel example there's no controller representing the did subject and therefore the did document can't be updated once published. While it's currently defined that "A DID can have more than one controller", we don't make any mention about what happens if the DID has no controller (e.g. it's just a resource).

This is where the language around controller becomes more important to me. Saying that a DID can be controlled by no one makes little sense to me. Isn't it just a static resource then at which point I'd ask why I need a publicKey (not required) or service endpoint (required but can be empty I believe)?

[Oskar-van-Deventer]

Please see PR #213. It uses the term "allows a controller ...". As @jandrieu already highlighted, DIDs can be abandoned by its controller immediately after the creation of the DID.

[brentzundel]

@kdenhartog Also see @talltree 's comment here. Specifically:

The DID Subject may need to be identified by the DID Controller for reference purposes only and have a static description that never needs to change. In this case the DID Document never needs to have any cryptographic keys at all.

[kdenhartog]

After reading through the comments in here and in #233 I can now understand where this is coming from and can see use cases that would be suited for this. I think you'll still run into implementation concerns with most ledgers by doing this, but that's up to the implementers to figure out not the spec.

[jandrieu]

Apropos of other conversations about did control, what DIDs do that is unique in the world is provide identifiers for which you can prove control without reliance on a trusted third party.

Content-based DIDs don't prove control. The only prove knowledge.

The defining characteristic of a DID is that someone can prove control, typically by demonstrating knowledge of a true secret. To the extent that that secret is no longer secret, proving control no longer differentiates the controller from the general public. The magic of public/private key cryptography is that you can publicly reveal information (the public key) which enables verification of certain mathematical operations performed by the private key. As long as that private key is legitimately secret, then proof of control has meaning.

This is the hook.

If all you need is to verify the content of the Subject, then you don't have a DID you just have a content-specific identifier. Useful and decentralized, but it doesn't do any of the things DIDs do wrt demonstrating proof of control.

[kdenhartog]

@jandrieu

I disagree about your assertion that proof of knowledge is not proof of control. Based on my understanding of @ChristopherA #122 (comment) the "ownership" key in BTCR is doing just that. It's asserting proof of knowledge of the public key at a later date by committing to that value ahead of time. Or as he states, is able to reveal the public key to assert proof of ownership. In other words, the process by which someone reveals a private key to assert the ability to derive a public key that proves knowledge of the public key which is verifiable by the hash in the DID Document (as it is today) is the same as having the secret knowledge in the first place in my opinion. It's just one less level of indirection. Mind you, I'm likely butcher my understanding of BTCR as I haven't worked with it enough, so please correct my misunderstanding of how it works if so. Preferably a link to where this is documented so I can read more if possible.

A second point, that I'd like to make is that proof of knowledge is not excluded by the definition of "verification method".

A set of parameters required to independently verify a proof, such as an identifier for a public/private key pair that would be used in the proof.

sharing the committed knowledge of the hash is "a set of parameters" and they are "required to independently verify a proof" if the hash algorithm is cryptographically secure.

I'd also like to point out that the crux of your argument that differentiates proof of knowledge commitment verification to PKI verification is not testable.

To the extent that that secret is no longer secret, proving control no longer differentiates the controller from the general public.

There's no way to know in a PKI based DID if a private key hasn't been broadcast to the world outside the DID Document, so I don't think this is a valid nuance to the mental model we should be building off of.

[jandrieu]

My point about secret v non-secret is that in order for the hash to be verified, the content MUST be exposed. Proof of control of private keys is precisely useful because you can prove you know the secret without revealing it.

This is the fulcrum on which all public/private key cryptography depends. It's a profoundly different architecture than the content-revealing verification that a hash matches a given piece of content.

You may be right about BTCR's use of hashes. Rotation requires proving control of the private key and I would have expected demonstrating proof of control of a BTCR would reveal the public key, but not the private key. I'll have to defer to people who understand it better.

My point is that we can prove essentially nothing about who the subject is with DIDs. All we can prove is that someone has control over a private key, which we take as either proof of control over the DID or authorization to authenticate on behalf of a DID.

From that control, we can bootstrap a system of credentials issued "to" that DID because either the controller or a delegate of the DID proved their control or delegate status, and claimed that DID is an appropriate subject for a requested credential. Then upon presentation of that credential, they can again prove control (or authenticate) and establish a link between themselves as holder and their authority to act on behalf of the DID. Thus at both creation and presentation, proof of control over the DID is what establishes appropriate use.

If no one can prove control, nor authenticate on behalf of a DID, then treating the DID as any particular subject is a fools game. Anyone can say anything about any DID. Only a controller or delegate can demonstrate they are suitable parties for interactions on that subject's behalf.

For content-based DIDs, you can't demonstrate control. The very hook that allowed a provable link between a given identifier and someone using that identifier is gone.

Yes, you could put a hash in a registry and let a trusted third party decide who gets to say things about that hash-as-identifier, but you can only ever prove knowledge of a revealed piece of content. The rest is up to that third party.

Approaches that simply link an identifier to content have no control framework, which to my mind suggest they cannot be used for the proof-of-control that is core to the DID architecture. This is the essence of the conversation about adjusting our notion of control. But it isn't just about having a deterministic link between an identifier and a piece of content, it is about using secrets to demonstrate control without relying on a third party. Content identifiers don't demonstrate control and therefore can't be used in the way DIDs can be: as a means test for proving the propriety of certain actions by an otherwise unknown actor.

IMO, proving control is the fundamental to how DIDs do what DIDs do.

Sure, let's have content-specific identifiers. That's useful. I just don't see how they enable secure interaction with anything, how they prove control. I don't see how they are DIDs in the sense that this group has been developing.

[pknowl]

@jandrieu - I think everyone understands what you are saying, what you've said and what your opinion at this juncture is. I think a definite line can be drawn there. At this stage, the argument is more philosophical than technological.

I strongly believe that a decentralized data network will be much more stable if we only have one identifier throughout the space - _DIDs for everything_. That would allow us to put all other identifier standards out to pasture with a graceful "thank you for getting us to this point."

I'm attaching a mini-deck so that everyone can visualise exactly what that means. _DIDs for everything in the big blue circle_. See first slide.
Identifiers.pdf

Can we close this particular thread and all hop on #233 instead? The two threads are now talking about exactly the same philosophical issue.

[SmithSamuelM]

A digital signature is also a collision resistant hash. Using a signature as the basis for a self-certifying identifier simultaneously provides a content addressable identifier and an identifier under the provable control of an asymmetric key-pair. The public key may be disclosed at time of proof of control. Likewise a content addressable self-certifying identifier can be derived by chaining successive one-way functions. The first is to generate the public key, the second is to create a content hash on content that includes both the document and the public key. This content addressable identifier has provable control by the associated key-pair. Given we can have secure ( provable control) content addressable identifiers why would we foster insecure content addressable identifiers? Haven’t we learned our lessons over the last three decades from the weaknesses of insecure identifiers, e.g. IP addresses?

If we are not securely identifying we are nothing.

Sent from my iPad

On Mar 25, 2020, at 00:27, Paul Knowles [e-mail] wrote:


@jandrieu - I think everyone understands what you are saying, what you've said and what your opinion at this juncture is. I think a definite line can be drawn there. At this stage, the argument is more philosophical than technological.

I strongly believe that a decentralized data network will be much more stable if we only have one identifier throughout the space - DIDs for everything. That would allow us to put all other identifier standards out to pasture with a graceful "thank you for getting us to this point."

I'm attaching a mini-deck so that everyone can visualise exactly what that means. DIDs for everything in the big blue circle. See first slide.
Identifiers.pdf

Can we close this particular thread and all hop on #233 instead? The two threads are now talking about exactly the same philosophical issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[brentzundel]

We've gotten some clarity in the spec around what DIDs may identify.
Since the introduction now states that

A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies.

and

A DID document might contain the DID subject itself (e.g. a data model).

I think the only thing remaining before this can be closed is a PR that introduces a content or a subject property.

[dlongley]

I would think content or subject would be more like "additional/alternative representation of the subject" (some kind of name that expresses this vs. saying "the actual subject is over here, this doesn't count") since the DID Document is already expressing information about the DID subject. I'd be -1 to subject for that reason ... not sure how I feel about content (if it adequately captures the concept).

[talltree]

@dlongley What you say would be true except for the case where the subject of the DID is in fact a digital object (e.g., a schema, or a schema overlay object) that is contained entirely within the DID document. What Brent and I are going to propose in the PR is a standard DID doc property for this purpose. I prefer the name of this property to be subject because then it is self-evident that the digital object contained in the subject property is in fact the subject of the DID.

[dlongley]

@talltree,

I think it's a bit odd to say that the subject of the DID subject is this other thing. Wouldn't it be better to say that there is a digital representation X of the DID subject? Thinking in triple/sentence form:

<did:example:1234> <subject> <some_digital_value>

Or:

<did:example:1234> <representation> <some_digital_value>

The former here means that the subject, identified by did:example:1234, has a subject of some_digital_value. I think that's what is odd.

The latter here means that the subject, identified by did:example:1234 has a representation of some_digital_value. That sounds right to me -- doesn't it match what you're going for more cleanly? I'm happy for representation to be bikeshedded further in some way, but subject doesn't seem to fit the bill. Thoughts?

[talltree]

@dlongley I had to read your comment twice— like one of those optical illusions you have to stare at to see it another way.

But then I "got" it—that while the subject of the DID is a digital object, the actual markup inside the property in the DID document is a specific representation of that digital object. (Your example of how it would look as an actual RDF triple really helped.)

So I want to cook on it a little bit, but my initial thought is that representation is in fact a good name for the property.

@brentzundel and @ken-ebert (and anyone else interested in this use case), please do weigh in with your thoughts.

[peacekeeper]

One downside I see with representation is the following: If the resource identified by the DID is a digital object (schema, etc.), then shouldn't dereferencing that DID return only a representation of the resource, as opposed to returning a DID document that contains a representation of the resource?

Or put differently, isn't the DID document itself already a representation of the resource identified by the DID?

I'm not sure if the proposed property names capture this well enough.

I would like to offer the property name value for consideration (with the meaning of rdf:value). This way we could express cleanly that all properties in the DID document describe the subject, but here is one property that contains the "main value" of the subject.

[peacekeeper]

This thread also reminds me of this older comment which has left an impression on me: https://github.com/w3c/did-core/issues/65#issuecomment-558838589. Quoting from it:

We made a mistake by calling something a "DID Document". There is no such thing. There is a DID, that identifies a resource, and when you dereference it, you get a representation of that resource. It's information at that point in time... and that's all it is... and calling it a DID Document is confusing people.

[brentzundel]

Still waiting on a PR. @talltree is working on it .

[brentzundel]

This issue is related to the representation property #348, the proposed appendices #373, and #355 the alsoKnownAs and sameAs properties.
We plan to discuss this today on a special topic call (relational link types).

[brentzundel]

We had a special topic call to discuss this. The steps to move forward are to introduce a type property that will allow a user to specify the type of the document e.g., so that a DID document can be both a DID Document and a schema.
also waiting on alsoKnownAs

[OR13]

related https://github.com/w3c/did-core/issues/421

[msporny]

The steps to move forward are to introduce a type property that will allow a user to specify the type of the document e.g., so that a DID document can be both a DID Document and a schema.

Looks like this isn't going to make it into the specification because of concerns around privacy. Language will be added to the specification noting that clarifying what DID might identify can lead to privacy dangers. it will still be possible to do so, but the specification will take a stance that for individuals, it's dangerous. We have time scheduled during the upcoming F2F to discuss this topic.

also waiting on alsoKnownAs

This looks like it's going to go through as soon as the W3C Social Web CG approves the term.

[brentzundel]

Since the type property has not gained consensus, I think the best option now would be to continue discussion on a representation property as a possible resolution to this issue.

[rxgrant]

The type idea was very dangerous to section 10.4, Herd Privacy.

https://www.w3.org/TR/did-core/#herd-privacy

I think these representational issues don't belong in DID-core at all.
This spec is not trying to build a giant database of people and
things. It's not meant to help a computer sort you out for easier
targeting. There is no value (to users of DIDs themselves) in trying
to make a database aggregation feature part of the core spec.

Use of DIDs will sometimes never reveal a DID Document publicly, but
that is harder to achieve than public listings. In anticipation of
the very common failure modes of data leaks, DID Documents should
stick to the basics: identifier, key material, endpoint.

Take everything else to a DID method. You even have an open world
model to play with, so your application can do whatever it wants
within existing DID methods. Stop making this about sorting me.

[brentzundel]

@rxgrant, I completely agree with your interpretation of what the spec is not supposed to be used for. With respect, this issue has nothing to do with identifying, sorting, or dereferencing people, and a solution for this issue which makes that possible or likely should not be pursued.
I share many of your concerns about possible misuse of DIDs, and feel strongly that properties which compromise the privacy of individuals are inappropriate within DID documents. I have never argued for an open world model for DID Documents, and personally feel that public DID documents for individuals should never be used. Nor have I ever argued for nor encouraged database aggregation or crawling of DID Documents.

This issue is about including an information resource within a DID document if the DID identifies an information resource. type was introduced as a possible mechanism for doing so, and was rejected for its privacy implications.
If you have similar, specific concerns about a representation property, or other concerns about how it may be misused, please share them.

[agropper]

What's an information resource?

On Mon, Nov 2, 2020 at 11:21 AM Brent Zundel [e-mail]
wrote:

@rxgrant https://github.com/rxgrant, I completely agree with your
interpretation of what the spec is not supposed to be used for. With
respect, this issue has nothing to do with identifying, sorting, or
dereferencing people, and a solution for this issue which makes that
possible or likely should not be pursued.
I share many of your concerns about possible misuse of DIDs, and feel
strongly that properties which compromise the privacy of individuals are
inappropriate within DID documents. I have never argued for an open world
model for DID Documents, and personally feel that public DID documents for
individuals should never be used. Nor have I ever argued for nor encouraged
database aggregation or crawling of DID Documents.

This issue is about including an information resource within a DID
document if the DID identifies an information resource. type was
introduced as a possible mechanism for doing so, and was rejected for its
privacy implications.
If you have similar, specific concerns about a representation property,
or other concerns about how it may be misused, please share them.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/199#issuecomment-720574892, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABB4YPPBUAG7MBRNUNEFC3SN3MCJANCNFSM4KXMHSZQ
.

[brentzundel]

some examples of information resources this issue is concerned with: https://github.com/w3c/did-core/issues/199#issuecomment-589823251

[msporny]

What's an information resource?

https://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14#sec-information-resources

WARNING: That document is a very deep rabbit hole, don't go down the rabbit hole. That particular rabbit hole has eaten decades of peoples lives... and it's still hungry.

[agropper]

This might be a good thread to capture my suggestion: "Treat DIDs linked to
a VDR the way we treat Bitcoin addresses." on
https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.ga6aa7427ae_1_87

Based on this principle, a DID on a public VDR would say nothing more about
the result of dereferencing said DID than an address on that VDR does. In
both cases, the identifier is subject to a specified control structure and
is self-sovereign in the sense that it "can't be taken away." Under GDPR
and future privacy domains, we would treat the DID document as if it were,
for example, a smart contract on Ethereum.

On Mon, Nov 2, 2020 at 1:42 PM Manu Sporny [e-mail] wrote:

What's an information resource?

https://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14#sec-information-resources

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/199#issuecomment-720654526, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABB4YP6SF7G46FUXKFRIITSN34SPANCNFSM4KXMHSZQ
.

[msporny]

There is a partial answer to this in #460. There isn't a specific solution to this yet.

[brentzundel]

The specific solution will need to be raised in a PR. I will try to get one in.

[dlongley]

@jandrieu may have comments related to this in #457 (with specific text suggestions).

[jandrieu]

@dlongley Not sure what you might have been trying to highlight. I believe my concerns have already been stated in the comments here: DIDs can identify anything, but IMO we shouldn't enshrine DID Documents as delivery vehicles for resources. If methods want a resolver to return additional resources along with a DID Document, that is an entirely appropriate use of meta-data.

So, what Brent is asking for could reasonably be met by defining a meta-data field that contains a representation of the resource. That would be fine.

The devils will be in the details. So, I think we need a PR to get to specific language.

[brentzundel]

I began a PR to address this, but got stuck.

If I remember correctly, we've defined three buckets:

1. data about the DID Subject - this goes in the DID Document
2. data about the DID Document - this goes in the DID Document Metadata
3. data about DID Resolution - this goes in DID Resolution Metadata

@jandrieu I'm not opposed to using metadata to deliver content identified by the DID as part of the resolution process, but which bucket should it go in? My mental model puts it in the DID Document because it is data about the DID Subject, but I understand the desire to keep DID Documents as simple as possible and not overload them.

The options that I see for addressing this issue:

1. define a DID Document property that would contain the DID Subject
2. define a new metadata category (DID Subject Metadata?) that would be delivered as part of DID resolution, then define a property that would contain the DID Subject.
3. define a new DID Resolution Input Metadata property to indicate that the resource resolved should be the DID Subject rather than the DID Document
4. define a new DID Parameter to indicate that the resource returned should be the DID Subject rather than the DID Document.

I'm also open to other ideas if anyone has some.

[peacekeeper]

-1 to option 2 (define a new metadata category).

I'm pretty sure content identified by the DID belongs in the DID document (option 1).

[jandrieu]

@peacekeeper I'm pretty sure that what is in the DID Document should be about how to interact securely with/on behalf of the DID Subject and not a transport mechanism for any resource(s) the DID might refer to.

Seems to me that if--in addition to the DID Document--a representation of the DID Subject is returned by the resolver, then that is resolution metadata. That is, the resolver needs to communicate that its response includes a representation of the subject.

Putting any attributes or representations about or of the DID Subject that is embedded in the DID Document undermines herd privacy.

Remember, the DID refers to a DID Subject. It is not intended to be a URL for the DID Subject but a URI. Per 3986 the resolution process should return an "access mechanism and the appropriate parameters necessary to dereference a URI". That is what is in the DID Document. It is not the Subject itself.

If the DID Method provides a way for a resolver to also return the resource itself, that would be dereferencing the DID rather than simply resolving it. I can accept that returning that resource in the same method call as the resolution is reasonable as Resolution Metadata, since in the resolution process should return the DID Document, not the resource.

We could also define the API such that the resolution request specified dereferencing. In THAT case, if the DID can be dereferenced to a resource, dereferencing should return the resource instead of the DID Document, whether its from a DID-URL or from a DID of a method that is capable of returning the resource in the same step as returning the DID Document. With this representation property in the DID Document, resolution now is indistinguishable from dereferencing for those DID, which is both a layer violation and a herd privacy problem.

TLDR: Resolution should return the DID Document, not the resource. But including the resource in resolution meta-data would address use cases like @brentzundel's.

I'll repeat arguments I've made elsewhere to see if there is any support among us collaborators.

The intention of DIDs was to provide a way to prove control over an identifier (using publicly verifiable data) without reliance on a trusted third party--a sharp break from all previous identification mechanisms.

The use case described by Brent doesn't do that. did:schema doesn't do that.

You cannot use did:schema to prove who controls that resource or the identifier. All you're doing is, at best, pointing to a static resource on a content-addressable network (which cannot be updated while retaining the initial DID). So, you can't even prove control over the identifier through ANY mechanism, not even by changing the DID Document: either the DID Document is deterministically generated from the DID (as in did:schema) so changing the Document requires changing the DID, or changing the DID Document would change the DID (as was discovered in early IPFS-based DIDs where the DID itself was a content-based identifier).

You can't authenticate with did:schema.
You can't sign with did:schema.
You can't rotate or revoke with did:schema.

In short, those DIDs really should be CIDs, not DIDs. However, since we have failed to define what can and can't be a valid DID Method, we need to manage the presence of these outlier methods.

That said, I have no problem with a resolution process that enables resolution and dereferencing in the same step, and DID Methods that support that. That seems to be the key goal in Brent's request. That would make it resolution meta-data.

Another option would be to simply make "representation" a method-specific property. It certainly does not seem to have the broad-based support necessary to make it a core property.

Do we have two different implementations of this? Or even multiple method definitions that intend to implement it?

[kdenhartog]

Where you're going with this @jandrieu is something that I think I can get on board with. In the case of the DID Document for did:schema would this still be a valid in your eyes?

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:schema:evan-ipfs:xsd:QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5",
  "service": [
    {
      "id": "did:schema:evan-ipfs:xsd:QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5#get",
      "type": "GetSchemaService",
      "serviceEndpoint": "https://ipfs.evan.network/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5"
    }
  ]
}

And the Resolution object would be something more like this:

{
    "@context": "https://w3id.org/did-resolution/v1",
    "didDocument": {
            "@context": "https://www.w3.org/ns/did/v1",
            "id": "did:schema:evan-ipfs:xsd:QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5",
            "service": [{
                 "id": "did:schema:evan-ipfs:xsd:QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5#get",
                 "type": "GetSchemaService",
                 "serviceEndpoint": "https://ipfs.evan.network/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5"
               }]
         },
    "didResolutionMetadata": {
        "content-type": "application/did+ld+json",
        "retrieved": "2024-06-01T19:73:24Z"
    },
    "didDocumentMetadata": {
        "created": "2019-03-23T06:35:22Z",
        "updated": "2023-08-10T13:40:06Z",
        "resource": "<xs:schema>
    <xs:simpleType name="stringtype">
        <xs:restriction base="xs:string"/>
    </xs:simpleType>
    <xs:simpleType name="inttype">
        <xs:restriction base="xs:positiveInteger"/>
    </xs:simpleType>
    <xs:simpleType name="dectype">
        <xs:restriction base="xs:decimal"/>
    </xs:simpleType>
    <xs:simpleType name="orderidtype">
        <xs:restriction base="xs:string">
            <xs:pattern value="[0-9]{6}"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="shiptotype">
        <xs:sequence>
            <xs:element name="name" type="stringtype"/>
            <xs:element name="address" type="stringtype"/>
            <xs:element name="city" type="stringtype"/>
            <xs:element name="country" type="stringtype"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="itemtype">
        <xs:sequence>
            <xs:element name="title" type="stringtype"/>
            <xs:element name="note" type="stringtype" minOccurs="0"/>
            <xs:element name="quantity" type="inttype"/>
            <xs:element name="price" type="dectype"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="shipordertype">
        <xs:sequence>
            <xs:element name="orderperson" type="stringtype"/>
            <xs:element name="shipto" type="shiptotype"/>
            <xs:element name="item" maxOccurs="unbounded" type="itemtype"/>
        </xs:sequence>
        <xs:attribute name="orderid" type="orderidtype" use="required"/>
    </xs:complexType>
    <xs:element name="shiporder" type="shipordertype"/>
</xs:schema>"
    }
}

Note: embedding XML in JSON is not the point of the example and it's only there for accuracy of the example. In any case figuring how to handle that would likely need to be considered if the DID Doc Metadata was expected to be return in JSON, but we'll leave that for a separate concern in DID Resolution.

[peacekeeper]

We could also define the API such that the resolution request specified dereferencing.

We have already defined both "resolving" and "dereferencing":

 resolve ( did, did-resolution-input-metadata )
     -> ( did-resolution-metadata, did-document, did-document-metadata )

 dereference ( did-url, did-url-dereferencing-input-metadata )
         -> ( did-url-dereferencing-metadata, content-stream, content-metadata ) 

Keep in mind that every DID is also a DID URL.

Dereferencing a DID URL can potentially return a representation of a resource that is not the DID document; I think this is consistent with what you're saying @jandrieu .

[jandrieu]

@peacekeeper Yes. That's correct.

And so, if you put a representation in the DID Document, then you can no longer resolve a DID without also dereferencing it.

That is the layer violation, because you can no longer distinguish resolution from dereferencing.

[iherman]

The issue was discussed in a meeting on 2020-12-08)

• no resolutions were taken

View the transcript

3. Issue 199

_See github issue #199._

Brent Zundel: Possibly last of the issues that need to be discussed — at this point there are a few changes on how we could move forward

Brent Zundel: https://github.com/w3c/did-core/issues/199#issuecomment-738333023

Brent Zundel: Let's time box to 10 minutes to briefly discuss the issue — clarification of what DIDs might identify
… I feel awkward about talking about this — I raised it, but doing my best to not do it w/ my Chair and/or company hat on.
… This issue is about how to express information resources as part of information resource — there are four possible ways of doing this — define DID Document property to contain DID Subject, define new metadata category to return DID Subject, or define DID Resolution input metadata property to indicate that when DID is resolved, DID Subject should be returned rather than DID Document, or new DID Parameter.
… Jump on queue if you have suggestions/thoughts.

Manu Sporny: could you outline a concrete use case? I believe it is something like you have a schema that has a DID associated with it and you want to return the schema and not the DID document, but I might be misunderstanding?

Brent Zundel: Yes, we have an information resource that is a schema identified by DID — it is the DID Subject, resolution of DID would like DID Subject returned in addition to information returned in DID Document... important to see who controls the subject, and that is information representation in DID Document... initial attempt was content property, which then turned into representation, then type, which turned into a bad idea... how can we do this?

Adrian Gropper: I see this as a pure authorization problem. I know there's been discussion about this over the weekend... see this entirely as an authorization issue.

Jonathan Holt: How do we do this w/ authorization? In IPID method, create submethod name, schema, same thing when you resolve DID Document, you can also resolve schema... ipid:schema: ... that's how we were going to handle it — how can we do this w/ authorization?

Markus Sabadello: I'd be opposed to allowing resolution of a DID — resolution not dereferencing, when you resolve a DID you can't get anything other than a DID Document.

Amy Guy: +1 to markus

Markus Sabadello: I would be open to saying that you resolve the DID and you get a DID Document, and that has a property that contains the subject... when you dereference a DID, you could get something other than the DID Document... we shouldn't change basic assumption, when you resolve a DID you get a DID Document.

Joe Andrieu: It's important to be able to resolve w/o dereferencing — this property wouldn't allow that when it's used... that seems to be a layer violation... could have impact on herd privacy. We should allow resolution as a distinct step from dereferencing.

Brent Zundel: good feedback

Drummond Reed: I was going to ask why Adrian thought this was an authorization problem?

Brent Zundel: It sounds like, of the options we went through — Joe is uncomfortable w/ option #1... wondering now about option 3 - as part of resolution input metadata, the entity resolving DID — also give me Information Resource identified by it, option 4, did parameter that is a URL that could be dereferenced to retrieve DID subject.

Adrian Gropper: the explanation is — entirely consistent w/ resolution should be separate from dereferencing... DID Document is a public document in general... as far as spec is concerned, we should consider it to be public — therefore, distinction between dereferencing needs to be protected by authorization step.

Markus Sabadello: Small modification about option 3- input metadata property to request DID Document or DID Subject... if we could change that to "dereferencing input metadata" resolving never returns anything other than DID Document... parameters or metadata properties --- dereference the did, metadata property, could return something other than DID Document... not mutually exclusive w/ option #4.

Ivan Herman: Listening to that, I don't understand the use case.
… When you say it returns the schema... does the method have the schema somehow in it's own database and it returns file containing schema, or does it return URL of schema which is somewhere on the Web, or does the method have to dereference to somewhere on Internet and returns that...

Brent Zundel: #1 — return the file.

Ivan Herman: Sounds like a narrow use case.

Brent Zundel: A large community cares about this use case.

Drummond Reed: Two quick points - as an editor, huge mistake to assume DID Document is public... we should make sure we cover that case, but there are thousands of use cases for DID Documents that are private — shared between peers... so to impose on the spec that all DID Documents would be public.

Orie Steele: Is it true that the desire to support schemas and did documents in the same system is to support certain ZKP credential formats such as Indy Credentials?

Drummond Reed: Interested in a parameter for requesting dereferencing — all for resolution, but if you want for efficiencies sake, compose URL that ask for dereferencing — that's option #4.

Brent Zundel: We have a minute left and then we need to move on... Excellent feedback so far.

Manu Sporny: veres one has a use case where we store capabilities on ledger, in veres one the DID doc is a capability itself. We have explored other things being stored in DID docs that are kind of like the use case brent outlined
… one workable thing would be why don't we create a narrow property called schema if you want to put a schema in a DID doc, adn we create other narrow properties
… we may be trying to overgeneralize this feature
… we need to be very specific about what we want
… keeping dereferencing separate from resolution is a good thing to do architecturally but it may confuse this because other parts of internet infrastructure may work that way so it may be a weird thing for people to understand
… trying to figure out the simplest way to address the issue, putting a specific property in a DID doc might be the first easiest way
… we can talk about the more complex things like resolution and deferenerncing giving back different things
… there's a use case in veres one that's sort of interested in figuring out the answer to this question but i'd like the group to pick the simplest thing that is nto going to create more cognitive overhead for developers

Drummond Reed I'm worried that we're going to end up with a growing list of properties being added to DID Spec Registries for all the different types of content that might want to be included in a DID document

Dave Longley: if you had a URL like this: "did:method:1234#representation" and it resolves to the DID Document "did:method:1234" and when dereferenced, you get whatever it says about "did:method:1234#representation" you get a technical separation of resolution/dereferencing

Drummond Reed: Agree with Dave

Dave Longley: (not unlike dereferencing verification methods)

Amy Guy: that narrow property sounds like an extension / for the registries rather than a core property

Joe Andrieu: regarding Drummond's comments — public vs. private — important thing isn't "all did documents are public"... rather, "herd privacy requires they be indistinguishable"... properties unique to subject can cause problems w/ herd privacy.

Brent Zundel: +1 to the importance of herd privacy

Ivan Herman: I understand the use case and accept it — maybe this is what Joe was saying — there is a layering issue... the method, as far as DID is concerned, does resolution and returns DID Document... but there is DID URL, which is different thing... method stores something other than DID DOcument, so you want to give separate access to other information — those two things are very different... I'd use a different access mechanism... DID URL might be the different tool for this... “I don't resolve now, I use other functionality”, these two things shouldn't be mixed.

Jonathan Holt: +1 to ivan

Markus Sabadello: we already have scenarios where dereferencing a DID URL returns something other than DID Document, service selection, for example — not a new idea.

Brent Zundel: Ok, that helps, will move on to issue processing

[kdenhartog]

Just read through the comments on why we might want this functionality. One of the core ones that I've been thinking it would be useful for would be to publish a revocation object (from rl-status-2020) to a ledger such that it can be resolved later.

An example of this would be if did:example:123 is resolved the returned "DID Document" (It's by definition a did document, but it definitely steps outside the original intent of the DID Document) would be:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vc-revocation-list-2020/v1",
    "https://www.w3.org/ns/did/v1"
  ],
  "id": "did:example:123",
  "type": ["VerifiableCredential", "RevocationList2020Credential"],
  "issuer": "did:example:456",
  "controller": "did:example:789",
  "issued": "2020-04-05T14:27:40Z",
  "credentialSubject": {
    "id": "did:example:123#revocation-status-list",
    "type": "RevocationList2020",
    "encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAP4GcwM92tQwAAA"
  },
    "proof": {
      "type": "Ed25519Signature2018",
      "proofPurpose": "assertionMethod",
      "created": "2020-04-05T14:27:40Z",
      "verificationMethod": "did:example:456#key1",
      "jws": "eyJ0eXAiOiJK...gFWFOEjXk"
  }
}

In this case, the DID Subject would be the RevocationList2020Credential and the DID Controller would be the DID defined in the the controller property. When the controller wishes to update the RevocationList2020Credential (say to provide an updated RevocationList2020Credential that they got from the issuer) they would submit an update to the VDR which would include the new encodedList value and it would be signed by a verification method from the "assertionMethod" verification relationship in did:example:789's DID Document. It's also possible that the "issuer" and "controller" could be inferred to be the same and as such the controller property could be dropped, but that felt less semantically precise given the case where the issuer is different than the controller because the controller is the publisher of the RevocationList2020Credential and the issuer is the signer of the actual RevocationList2020Credential. I'd assume that the standard case would actually have the same issuer and controller values though and both would be listed like above.

Of note, the language in the VC Data Model The value of the @context property MUST be an ordered set where the first item is a URI with the value https://www.w3.org/2018/credentials/v1. would likely be in conflict with the language in the DID Core spec An INFRA list, with first item the INFRA string https://www.w3.org/ns/did/v1, and subsequent items of type INFRA string or INFRA map. So we'd need to update one of those normative statements to make this possible.

[agropper]

This revocation issue goes back three or four years to the Healthcare
(Prescription) Use Case https://w3c.github.io/did-use-cases/#prescriptions
If the prescription is coded as a VC, it needs to be revocable by the
issuer (the doctor when they write another prescription) AND by the
pharmacist when they dispense the prescription. I guess the time has come
to deal with this.

On Tue, Dec 8, 2020 at 5:26 PM Kyle Den Hartog [e-mail]
wrote:

Just read through the comments on why we might want this functionality.
One of the core ones that I've been thinking it would be useful for would
be to publish a revocation object (from rl-status-2020) to a ledger such
that it can be resolved later. An example of this would be:

If did:example:123 is resolved the returned "DID Document" (It's by
definition a did document, but it definitely steps outside the original
intent of the DID Document) would be

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vc-revocation-list-2020/v1",
"https://www.w3.org/ns/did/v1"
],
"id": "did:example:123",
"type": ["VerifiableCredential", "RevocationList2020Credential"],
"issuer": "did:example:456",
"controller": "did:example:456",
"issued": "2020-04-05T14:27:40Z",
"credentialSubject": {
"id": "https://example.com/status/3#list",
"type": "RevocationList2020",
"encodedList": "H4sIAAAAAAAAA-3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAP4GcwM92tQwAAA"
},
"proof": { ... }
}

In this case, the DID Subject would be the RevocationList2020Credential
and the DID Controller would be the DID defined in the the controller
property. When the controller wishes to update the
RevocationList2020Credential (say to revoke a credential in the
encodedList) they would submit an update to the VDR which would include the
new encodedList value and it would be signed by a verification method
from the "assertionMethod" verification relationship in did:example:456's
DID Document. It's also possible that the "issuer" and "controller" could
be inferred to be the same and as such the controller property could be
dropped, but that felt less semantically precise given the case where the
issuer is different than the controller because the controller is the
publisher of the RevocationList2020Credential and the issuer is the signer
of the actual credential.

Of note, the language in the VC Data Model The value of the @context
property MUST be an ordered set where the first item is a URI with the
value https://www.w3.org/2018/credentials/v1. would likely be in conflict
with the language in the DID Core spec An INFRA list, with first item the
INFRA string https://www.w3.org/ns/did/v1, and subsequent items of type
INFRA string or INFRA map. So we'd need to update one of those normative
statements to make this possible.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/199#issuecomment-741136151, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABB4YO3NUQBZDA3PD2V543ST2R2BANCNFSM4KXMHSZQ
.

[msporny]

This PR is waiting on PR #460 to be merged and this issue will be closed after that PR has been merged.

[msporny]

PR #460 has been merged, closing.