Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarification on what DIDs might identify #199

Closed
brentzundel opened this issue Feb 18, 2020 · 70 comments
Closed

Clarification on what DIDs might identify #199

brentzundel opened this issue Feb 18, 2020 · 70 comments
Assignees
@talltree
Labels
PR exists There is an open PR to address this issue pre-cr-p1 Pre-CR high priority issue.

Comments

@brentzundel
Copy link
Member

brentzundel commented Feb 18, 2020 •
edited

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.
@brentzundel brentzundel self-assigned this Feb 18, 2020
@jandrieu
Copy link
Contributor

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
Copy link
Member

iherman commented Feb 19, 2020

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

talltree commented Feb 20, 2020 •
edited

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:

image

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
Copy link
Member Author

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
Copy link
Contributor

@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
Copy link
Member Author

brentzundel commented Feb 21, 2020 via email

@talltree
Copy link
Contributor

talltree commented Feb 21, 2020 •
edited

@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
Copy link

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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Member

kdenhartog commented Feb 24, 2020 •
edited

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.

@rhiaro rhiaro added the discuss Needs further discussion before a pull request can be created label Feb 25, 2020
@jandrieu
Copy link
Contributor

@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
Copy link
Member

iherman commented Feb 25, 2020

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 #183, in particular #183 (comment) ...

@peacekeeper
Copy link
Contributor

@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
Copy link
Contributor

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

@Oskar-van-Deventer Oskar-van-Deventer mentioned this issue Feb 28, 2020
Closed
@Oskar-van-Deventer
Copy link
Contributor

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"?

@Oskar-van-Deventer Oskar-van-Deventer mentioned this issue Mar 3, 2020
Merged
@brentzundel
Copy link
Member Author

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
Copy link

pknowl commented Mar 17, 2020 •
edited

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

@brentzundel
Copy link
Member Author

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
Copy link
Contributor

rxgrant commented Nov 2, 2020 •
edited

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
Copy link
Member Author

@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
Copy link
Contributor

agropper commented Nov 2, 2020 via email

@brentzundel
Copy link
Member Author

some examples of information resources this issue is concerned with: #199 (comment)

@msporny
Copy link
Member

msporny commented Nov 2, 2020 •
edited

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
Copy link
Contributor

agropper commented Nov 2, 2020 via email

@kdenhartog kdenhartog mentioned this issue Nov 15, 2020
Merged
@rhiaro rhiaro added the PR exists There is an open PR to address this issue label Nov 23, 2020
@msporny
Copy link
Member

msporny commented Nov 24, 2020

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

@brentzundel
Copy link
Member Author

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

@dlongley
Copy link
Contributor

dlongley commented Dec 1, 2020 •
edited

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

@jandrieu
Copy link
Contributor

jandrieu commented Dec 1, 2020

@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
Copy link
Member Author

brentzundel commented Dec 3, 2020 •
edited

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
Copy link
Contributor

-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
Copy link
Contributor

jandrieu commented Dec 4, 2020

@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
Copy link
Member

kdenhartog commented Dec 4, 2020 •
edited

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
Copy link
Contributor

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
Copy link
Contributor

jandrieu commented Dec 7, 2020

@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
Copy link
Member

iherman commented Dec 8, 2020

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: #199 (comment)

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
Copy link
Member

kdenhartog commented Dec 8, 2020 •
edited

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
Copy link
Contributor

agropper commented Dec 8, 2020 via email

@brentzundel brentzundel mentioned this issue Dec 9, 2020
Merged
@msporny
Copy link
Member

msporny commented Jan 5, 2021

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

@msporny msporny assigned talltree and unassigned brentzundel Jan 12, 2021
@msporny msporny removed the needs-special-call Needs a special topic call to make progress label Jan 28, 2021
@talltree talltree mentioned this issue Feb 1, 2021
Merged
@msporny
Copy link
Member

msporny commented Feb 1, 2021

PR #460 has been merged, closing.

@msporny msporny closed this as completed Feb 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@talltree talltree

Labels
PR exists There is an open PR to address this issue pre-cr-p1 Pre-CR high priority issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests