Decide what to do about 'proof' section and other DID Doc Metadata

[dmitrizagidulin]

Signing the DID Document itself (adding an OPTIONAL/recommended proof section, for example) would offer integrity protection / move towards the did docs being self-certifying.

Since the proof property (as well as other metadata fields such as created and updated) were removed from the DID Core spec, we need to make a decision on how to handle these in the did:web method.

Our options:

1. Put the metadata fields (proof, created etc) into the DID Document itself.
2. Store not the DID Document in the .json file on the web server, but instead embed it in a structure similar to the DID Resolution Result.

Example structure for option 1:

{
	"@context": "https://www.w3.org/ns/did/v1",
	"id": "did:web:example:com",
	"authentication": [{
		"id": "did:web:example:com#keys-1",
		"type": "Ed25519VerificationKey2018",
		"controller": "did:web:example:com",
		"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}],
	"service": [{
		"id": "did:web:example:com#vcs",
		"type": "VerifiableCredentialService",
		"serviceEndpoint": "https://example.com/vc/"
	}],
	"proof": {
		// signature over the whole DID document would go here.
	},
	"created": "2019-03-23T06:35:22Z",
	"updated": "2023-08-10T13:40:06Z"
}

Example structure for option 2:

{
	"@context": "https://w3id.org/did-resolution/v1",
	"didDocument": {
		"@context": "https://www.w3.org/ns/did/v1",
		"id": "did:web:example:com",
		"authentication": [{
			"id": "did:web:example:com#keys-1",
			"type": "Ed25519VerificationKey2018",
			"controller": "did:web:example:com",
			"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
		}],
		"service": [{
			"id": "did:web:example:com#vcs",
			"type": "VerifiableCredentialService",
			"serviceEndpoint": "https://example.com/vc/"
		}],
                "proof": {
                    // signature over the whole DID document would go here.
                }
	},
	"didDocumentMetadata": {
		"created": "2019-03-23T06:35:22Z",
		"updated": "2023-08-10T13:40:06Z"
	}
}

[awoie]

@dmitrizagidulin Is it correct to say that option 2) might be the more standard way of doing it because it these are registered terms in DID Document Metadata Properties? Option 1) will require extensions to context. Further, would be the proof contain a detached JWS?

[dmitrizagidulin]

@awoie - hmm, good question. Option 2 (the DID Resolution Result) is still very much in progress, spec wise. Buuut, you're right, we don't want to mess with the context in option 1.

And now that I think about it, if we adopt option 2, it'll give us room to put things like the optional 'audit trail' (KERI-like), and other sorts of metadata.

[dmitrizagidulin]

@OR13 - do you have any strong preferences here?

[OR13]

I personally don't like the idea of attaching proofs to did:web.... I had done the same thing with did:github, and it made it super frustating to update.... we even tried getting github actions to add the proof, which worked but is still not as elegant as just relying on the web server... I guess end of the day, if you really need the extra security, you can sign your did document.

just be prepared to manage all the update complexity that comes with that.

[OR13]

regarding "audit trails".... I think this is a waste of time... did web is not meant to be like other did methods, and leaving some obvious reasons to upgrade for higher security scenarios makes sense.

The simpler the spec, the better, did:web should be a gateway to better did methods, not try to compete with them.

[dmitrizagidulin]

@OR13 I see, ok. That still leaves the question open about what to do with "did doc metadata" and did:web. Which option do you prefer?

[OR13]

@dmitrizagidulin I prefer to pull caching / expiration / headers from the resource and simply reflect them in the did doc meta data.

[dmitrizagidulin]

@OR13 got it, ok. So that seems like a vote for option 2.

[awoie]

@mirceanis would also be good to get your opinion on that.

[mirceanis]

I also don't see a good reason to add proof section to the did doc.
Perhaps I'm not grasping it completely but it seems to me that it serves only as decoration and does not add any more trust to the result, while also complicating any implementation.
I very much like the idea about the metadata, if any, being compiled from the headers instead of being written to the json document.

[mirceanis]

@OR13 got it, ok. So that seems like a vote for option 2.

I'm not reading it that way :)

Also, I'm not putting any weight on either of the two options presented. I guess I'm opting for a third where the JSON that is served is the actual DID document and the server is free to present metadata as headers. It would be the resolver's option to present some of the headers as metadata.

[dmitrizagidulin]

So, the reason I'm reading it as a vote for Option 2 is -- the question here is what's the data model of a did:web DID Doc stored on disk. In order for the web server to present those metadata headers, it's gotta get them from somewhere. Which assumes the need for an envelope document like in option 2.

@mirceanis

it seems to me that it serves only as decoration and does not add any more trust to the result

But it does add one important part to the result - it adds the fact that the DID Document has not been tampered with (it's signed by the DID controller...).

[dmitrizagidulin]

And just to clarify, with option 2, the proof would not be in the DID Doc itself. It would be in the metadata section of the 'resolution result' data structure.

[mirceanis]

So, the reason I'm reading it as a vote for Option 2 is -- the question here is what's the data model of a did:web DID Doc stored on disk. In order for the web server to present those metadata headers, it's gotta get them from somewhere. Which assumes the need for an envelope document like in option 2.

So this would be applicable to documents that are served by "dumb" webservers, where the DID controller does not have too much control over the returned headers, right?

...
But it does add one important part to the result - it adds the fact that the DID Document has not been tampered with (it's signed by the DID controller...).

The reason why it looks like ceremony to me is that did:web already relies a lot on the trust in the webserver.
If the DID document is hosted or intercepted by a malicious server, it could very well replace the document entirely, including the DID controller and proof and a client would never be able to tell the difference unless some other out of band mechanism is in use.

---

On a separate note, I'm not very familiar with how DID document metadata is supposed to be used in practice, so my opinions here should not carry much weight.
If there is a proof section being served next to the DID document, who is supposed to verify it? if it's the resolver, then what types of proofs are accepted/recommended?
It complicates things a lot for a DID method that is supposed to be a bridge between old infrastructure(with its own cryptographic guarantees) and the new.

[OR13]

proof was removed from did core, and IMO, it's best not to use it at all on did documents.... trust in a did document should come from the DID Method and the VDR and the DID Controller OpSec.

if the proof is being used to pull the created timestamp... thats complicated, and as already pointed out, anyone with control of the web server can replace all of this... so proof does not add anything regarding trust... imo, its pure complexity and should be removed.

[dmitrizagidulin]

@mirceanis

So this would be applicable to documents that are served by "dumb" webservers, where the DID controller does not have too much control over the returned headers, right?

That's right, yeah. Which applies to a large chunk of the use cases did:web is addressing.

If there is a proof section being served next to the DID document, who is supposed to verify it? if it's the resolver, then what types of proofs are accepted/recommended?

I'm not sure if I fully understand the question. It's exactly the same as with Verifiable Credentials. Whoever is consuming the DID (so, holder, verifier, etc) can verify it. And which type of proofs - whatever the DID Method (or even your use case) agrees on.

@OR13

it's best not to use it at all on did documents.... trust in a did document should come from the DID Method and the VDR and the DID Controller OpSec.

So.. again, that seems like an argument for Option 2. "Trust in the VDR and DID Method" -- so, having a proof in the Resolution document (not the DID Document) increases trust in the VDR and the DID Method.

[OR13]

@dmitrizagidulin JSON-LD Proofs do not help increase trust with did:web. IMO, did:web should not have any normative requirements on JSON-LD Proofs.

did:web trust flows from web server control, and proof gives a false sense of security given this.

[dmitrizagidulin]

@OR13 but again, the question is not about proof specifically, or JSON-LD Proofs in general. (They are certainly not required). The main thing that we have to decide is - what should we do about any sort of metadata in the did document, with did:web.

[dmitrizagidulin]

@OR13 so far, if I'm understanding your argument correctly, you seem to be saying "no metadata in the DID Document at all". I think that's too limiting, and that there are several use cases that would be well served with a general metadata mechanism, on the data model level.

[OR13]

Yes, the DID WG has decided specifically to not put meta data in the did document, and the did spec registries has a separate section to make this even clearer: https://w3c.github.io/did-spec-registries/#did-document-metadata

I'm not against some "extension" which places meta data in the did document, but I think encouraging meta data in the did document generally for did web will be viewed as wrong by anyone familiar with other did methods.

[dmitrizagidulin]

@OR13 I remember that debate, sure. And one of the points that was made was -- the metadata belongs in the Resolution Result document. Which is exactly what we're talking about / proposing here.

[OR13]

https://github.com/transmute-industries/did-key.js/blob/master/packages/did-key-common/src/getResolver.ts#L113

https://w3c-ccg.github.io/did-resolution/#output-resolutionmetadata
https://w3c-ccg.github.io/did-resolution/#output-documentmetadata

^ all of these are places that are fine to put metadata imo...

[OR13]

I assume we are talking about the normative requirements did:web has on "resolution metadata" and "document metadata"

This issue is not very specific, and appears to be addressing both proof and meta data, hence the confusion.

[OR13]

To be crystal clear:

1. There should be no meta data in a did:web did document (no proof, updated or created).
2. I am ok with updated and created in did document meta data.

[dmitrizagidulin]

@OR13 ok, that seems pretty clear. (And like I said, that is exactly Option 2. Using the Resolution Result doc, which has 3 sections, the didDocument itself, the resolution metadata, and the didDocumentMetadata.)

[dmitrizagidulin]

@OR13 so the next question is.. so what does that look like, implementation wise? Is the .json file that's stored on a website - does it hold the overall Resolution Result doc, with the 3 sections? And then the resolver fetches that, does its thing, and only returns the didDocument part? That's kind of what I'm leaning towards.

[OR13]

@dmitrizagidulin yes, imo, it should be possible for the web server operator to control all 3 sections via vanilla JSON.

I would not be opposed to fancy HTTP Header based overrides for the did:web resolver to consider as well.

While we are on this subject, we might as well also consider did:web in JSON / CBOR / YAML...

IMO, a did web resolver builds a URL from https://w3c-ccg.github.io/did-resolution/#resolving-input

Makes a GET Request to the URL, and optionally considers headers returned in the response as taking priority over the field members.

[OR13]

did:web resolvers should implement:

resolveRepresentation ( did, did-resolution-input-metadata )
     -> ( did-resolution-metadata, did-document-stream, did-document-metadata )

over http... they should support representations other than JSON, such as CBOR.

I think its fine to "default them" to JSON, but we should allow to different JSON / JSON-LD at a minimum.

[kdenhartog]

Just to chime in here as well, I'm leaning more towards the direction of option 2 over option 1. I don't see many benefits to option 1 that don't eventually lead to did:web ending up diverging from many other expected usage patterns of other did methods (e.g. metadata in a separate portion of the did resolution result).

On the topic of representation I think what Orie brings up is a potential answer to supporting multiple representations by storing multiple representations on the server independently. This does open the potential for the different representations to be in different states though, so I lean more towards the option of having a resolver fetch the JSON representation translating it to the ADM and then translating it to the requested representation instead. The downside to this approach is that different representations will likely have different signature formats used such that some requesting parties (the client of the resolver doing the translator) may be unable to verify the signature method of the JSON representation.

However, as @mirceanis points out here there are ways to subvert the integrity of document in ways that aren't going to be detectable. At best for these types of things we'll want to state "MUST use TLS 1.2 or greater" and warn about DNS injection issues in the security section as well.

[dmitrizagidulin]

Just as an update -- as the DID Core spec is nearing its first CR, the editors of the did:web spec are actively discussing this topic.

[gribneau]

The DID Core specification is very consistent with existing HTTP content negotiation, using an accept element to specify desired representations and content types to identify those representations. In HTTP, accept is a request header containing one or more content type strings, content-type is a response header, and the process of identifying the best response is referred to as content negotiation.

This should be more efficient than mapping to specific URLs in the resolver, in that server-side logic would be able to identify the best available representation and deliver it in a single request. The explicit .json filename is a challenge in this scenario.

[vitorpamplona]

Pros and cons:

If in the headers then we might need to define a mapping function for each representation to an HTTP header. Maybe a dumb Base64 encoding of the raw DID Document Metadata contents in the chosen representation?

Two documents require two HTTP calls. Not super efficient, but not the end of the world either. Are there any security concerns when the web infra diverts the two calls to two different servers?

If inside the DID Document, then the spec should define that the did.json file is not a DID Document but an incomplete DID Resolution Result.

[gribneau]

1. in headers?

From a practical perspective, HTTP response headers are often limited in size, with 8k being a common default.

This is not required by the specification, and it is configurable, but it's worth noting.

[vitorpamplona]

1. in headers?

From a practical perspective, HTTP response headers are often limited in size, with 8k being a common default.

This is not required by the specification, and it is configurable, but it's worth noting.

Here is the limit of the most popular web servers:

• Apache - 8K
• Nginx - 4K-8K
• II S - 8K-16K
• Tomcat - 8K – 48K
• Node (<13) - 8K; (>13) - 16K

@gribneau would the map->HTTP header conversion require a dynamic web server? Are custom HTTP headers per file easy to set up/deal with on static servers and CDNs?

[gribneau]

would the map->HTTP header conversion require a dynamic web server?

It is plausible that one might be able to accomplish this with pre-rendered metadata in files that are then included as headers in the response document, which would not require a scripting engine.

Rendering those files will necessarily be dynamic, but if they don't change they could (plausibly) be served as static files.

Are custom HTTP headers per file easy to set up/deal with on static servers

This would fall squarely into the advanced category. Relatively few people are familiar with the layout of headers vs. content in HTTP responses.

and CDNs?

CDNs cache what the origins send, and this can include headers. Expect an 8k limit.

[gribneau]

Calls through an unsecured http and DNS MUST be accepted (The Security section can be deleted)

This requirement, particularly, is a non-starter for me.

Without TLS / SSL, an HTTP GET, together with any request headers, is visible in the clear to any network device that handles the traffic. The response, together with any headers, is similarly visible.

This change would expose use of did:web to surveillance.

[vitorpamplona]

Calls through an unsecured http and DNS MUST be accepted (The Security section can be deleted)

This requirement, particularly, is a non-starter for me.

Without TLS / SSL, an HTTP GET, together with any request headers, is visible in the clear to any network device that handles the traffic. The response, together with any headers, is similarly visible.

This change would expose use of did:web to surveillance.

I agree. Next time, I am not going to suggest a crazy example :)

[vitorpamplona]

So, looks like idea 3 is the leading contender. Do we all like this option? Please signal with a Like/Dislike reaction.

did.json will look like this: (this snippet is a variation of Option 2 from the first post)

{
	"@context": "https://w3id.org/did-resolution/v1",
	"didDocument": {
		"@context": "https://www.w3.org/ns/did/v1",
		"id": "did:web:example:com",
		"authentication": [{
			"id": "did:web:example:com#keys-1",
			"type": "Ed25519VerificationKey2018",
			"controller": "did:web:example:com",
			"publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
		}],
		"service": [{
			"id": "did:web:example:com#vcs",
			"type": "VerifiableCredentialService",
			"serviceEndpoint": "https://example.com/vc/"
		}],
	},
	"didDocumentMetadata": {
		"created": "2019-03-23T06:35:22Z",
		"updated": "2023-08-10T13:40:06Z"
                "proof": {
                    // signature over the "didDocument" would go here.
                }
	}
}

[peacekeeper]

what's the point of downloading a keyset document that an intermediary infrastructure can tweak around

It's one fundamental problem of the did:web method that it is easy for intermediary infrastructure to replace the entire DID document. I mean it's all relative, but a did:web is easier to manipulate than let's say a did:btcr.

• If the DID document (or DID document metadata) contains a proof created by the DID controller, then that proof is worthless, because an attacker could manipulate the DID document content including the public keys and proofs themselves.
• If the DID document (or DID document metadata) contains a proof created by some hardcoded external trusted signer (as suggested in a comment above), then that could make sense in some scenarios, but defining how to verify that is out of scope for individual DID methods and should be specified elsewhere.

Where is the DID Document Metadata stored for DID:WEB

This question is definitely in scope for a DID method spec, and I have been wondering myself how this could work for did:web. I don't have any preference here at all, but the original idea of DID document metadata was that it could originate from the DID controller and/or the DID method, or some combination of the two.

For example, in my mind it would be perfectly legitimate to say that in did:web, some DID document metadata (such as "updated") would be mapped from an HTTP header (such as "Last-Modified"). Note that the DID controller typically doesn't "manually" control such headers, it's the DID method that controls them. Whereas other DID document metadata (such as proofs) could come from a separate file on the webserver that the DID controller can edit however they like.

But again, I don't really have an opinion if and how exactly this should be supported by did:web.

[vitorpamplona]

I just realized that idea 3 breaks backward compatibility since most DID:WEB documents deployed right now have only the didDocument properties in the JSON. Since there is no versioning in the DID:WEB spec, DID:WEB resolvers would have to accept the old method (a direct DID Document in the JSON) and a new method (a JSON structure that includes the DID Document).

Is backward compatibility important at this stage? Or, because this is still a draft spec, we shouldn't care too much about it?

[msporny]

Is backward compatibility important at this stage? Or, because this is still a draft spec, we shouldn't care too much about it?

Backwards compatibility is not important at this stage. Until did:web achieves standardization and significant production deployment, we should be willing to change it. Experimental implementations will have to determine how they might keep backwards compatability if its important to them. For example, you could support both the "old style" and "new style" mechanisms described above by just checking for the existence of a few fields. That said, we shouldn't memorialize that experimental backwards compatibility in the specification in order to keep implementations as simple as we can achieve.

[vitorpamplona]

Hi all,

Please review PR #63.

Following the discussion here, the PR proposes:

1. Changing the nature of the did.json document to become a DID Resolution Document that contains a DID Document and not the DID Document itself.
2. Establishing the presence of DID Document Metadata with possibilities of adding cryptographic proofs to verify DID Documents.
3. Allowing multiple representations (JSON, JSONLD, XML, CBOR, etc) of the DID Resolution Document for the same DID:WEB based on DID Resolution Options

[vitorpamplona]

Hi all,

@msporny requested to move the proposed (#63) proof section from the DID Document Metadata to the DID Document itself.

I am happy to do it either way (in the DID Document or in the DID Document Metadata). But since so many of you have said here that proof should not go in the did document, what do you think? Do we have any consensus on this?

[gribneau]

I am comfortable either way.

I view adding signatures as a net positive, but remain agnostic on the question of placement in the DID document vs the DID metadata.

[msporny]

I am happy to do it either way (in the DID Document or in the DID Document Metadata). But since so many of you have said here that proof should not go in the did document, what do you think? Do we have any consensus on this?

I think the only viable answer here is "both". Implementers will want to secure the DID Document itself (provided by the DID Controller), and they will also want to provide a digital signature on the metadata associated with the DID Document (provided by the Verifiable Data Registry and/or the DID Resolver), and possibly over the entire resolution result (provided by the DID Resolver). All of those are valid use cases, and luckily, Data Integrity allows for all of that to happen. That said, if people want to use JWTs or some other mechanism that requires base64 encoding before signature, it will complicate matters.

Something to keep in mind as people weigh in... this isn't an either/or decision, IMHO.

[vitorpamplona]

Maybe we need a table on what types of proofs are acceptable in what places.

Type	DID Document	DID Document Metadata	DID Resolution Metadata	DID Resolution Result
Proof by a DID Controller	✅	✅	🚫	🚫
Proof by a Verifiable Data Registry	🚫	✅	🚫	🚫
Proof by a DID Resolver	🚫	🚫	✅	🚫

Does this make sense?

What's an example of a Verifiable Data Registry for DID WEB?

[vitorpamplona]

For JWTs, do we prefer something like:

{
  "didDocument": {
    "id": "did:web:example:com",
    "authentication": [{
      "id": "did:web:example:com#keys-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:example:com",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }],
    "service": [{
      "id": "did:web:example:com#vcs",
      "type": "VerifiableCredentialService",
      "serviceEndpoint": "https://example.com/vc/"
    }],
  },
  "didDocumentMetadata": {
    "created": "2019-03-23T06:35:22Z",
    "updated": "2023-08-10T13:40:06Z",
    "proof": {
      "type": "JwtProof2020",
      "jwt": "xxxx.yyyyy.zzzz"
    }
  }
}

or like this:

{
  "didDocument": {
    "id": "did:web:example:com",
    "authentication": [{
      "id": "did:web:example:com#keys-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:example:com",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }],
    "service": [{
      "id": "did:web:example:com#vcs",
      "type": "VerifiableCredentialService",
      "serviceEndpoint": "https://example.com/vc/"
    }],
    "proof": {
      "type": "JwtProof2020",
      "jwt": "xxxx.yyyyy.zzzz"
    }
  },
  "didDocumentMetadata": {
    "created": "2019-03-23T06:35:22Z",
    "updated": "2023-08-10T13:40:06Z",
  }
}

and since the JWT has a copy of the payload within itself, do we allow this? This is the equivalent to the LD-Signatures proof format, but for native JWT, where the didDocument is verifiably found in the yyyy section. In the previous method, the verifier needs to manually check if the yyyy section of the JWT matches the didDocument copy.

{
  "didDocument": "xxxx.yyyyy.zzzz"
  "didDocumentMetadata": {
    "created": "2019-03-23T06:35:22Z",
    "updated": "2023-08-10T13:40:06Z",
  }
}

This is important because there is also a CWT (using CBOR), where the same questions have to be asked.

[gribneau]

the JWT has a copy of the payload within itself

I generally prefer detached signatures to avoid duplicating data.

[vitorpamplona]

I don't like the confusion of the proof in the DID Document being a signature about the DID Document while the proof in the DID Document Metadata being about the DID Document as well and not the DID Document Metadata itself.

Maybe we need a different field name when the proof of the DID Document is placed inside the Metadata? didDocumentProof?

[msporny]

I don't like the confusion of the proof in the DID Document being a signature about the DID Document while the proof in the DID Document Metadata being about the DID Document as well and not the DID Document Metadata itself.

-1 to "the proof in the DID Document Metadata being about the DID Document".

Maybe we need a different field name when the proof of the DID Document is placed inside the Metadata? didDocumentProof?

-1 to this as well.

This conversation is reviving all that is terrible about how JWS and JWTs are used in practice. If you want to use proof, that is about signing the object that it's a part of, full stop. Don't do anything else with it, you'll confuse things greatly.

You could add things like didDocumentProof, but again, now you're doing that because JWTs are not capable of being natively embedded... they are external proofs and thus they require you to either wrap your entire data structure you're signing, or contort your data structures to fit into the JWTs-are-the-center-of-the-world data model (by inventing some sort of referencing "the data really lives over there and you must process it in this bespoke special way" solution). You're effectively defining a specific type of digital signature that is only valid in a DID Document Metadata section and making application-layer logic more complex as a result. JWTs are not fit for purpose for this kind of use case (where you are trying to achieve multiple signatures from multiple parties over subsets of data in the same document).

If you're going to use proof, use it in the way it was intended -- embed it in the objects you wanted to sign and you're good. No complex cross-referencing of subparts of a document.

If you want to try and shoe-horn non-embedded signatures into these responses, you're going to have to standardize something to do that, or create a one-off special purpose signature for DID Document Metadata. If you are going to do the latter, I expect there will be strong push-back due to the application layer complexity introduced with those type of half-baked approaches.

The only other alternative for JWT-based signatures that feels possibly workable is embedding the entire object being signed in the metadata, which results in duplication of content.

[OR13]

This conversation is reviving all that is terrible about how JWS and JWTs are used in practice.

It's also reminding us that VC WG has not yet defined proof.

You could make the entire resolution response be a JWS for JSON + JSON-LD and a CWS for CBOR.

[vitorpamplona]

This conversation is reviving all that is terrible about how JWS and JWTs are used in practice.

I agree, but we can either say that JWS and JWT MUST NOT be used OR we MUST provide the right way for people to use them. Not addressing the issue with finality is terrible for interoperability.

There is also SAML2 Assertions to deal with when the representation is XML

Of course, Linked proofs can be written in XML-LD and CBOR-LD as well. But that would simply follow the same solution for JSON-LD.

[msporny]

You could make the entire resolution response be a JWS for JSON + JSON-LD and a CWS for CBOR.

Please provide a complete proposal so that we can evaluate it. Note the requirements, there are three pieces of information that need to be digitally signed by three different parties, and then carried in the DID Resolution Response.

That proposal exists for Data Integrity (just add a proof to each sub-part of the response you want to have covered).

Of course, Linked proofs can be written in XML-LD and CBOR-LD as well. But that would simply follow the same solution for JSON-LD.

Yep, exactly. So we have at least one solution that is serialization format agnostic (granted, XML-LD doesn't exist yet... but the JSON and CBOR serializations certainly do exist). I suggest we don't try to support XML at this point in time unless we get large customer demand for it.

There is also SAML2 Assertions to deal with when the representation is XML

Who is currently planning to return SAML2 Assertions in XML format in a DID Resolution response?

[vitorpamplona]

Who is currently planning to return SAML2 Assertions in XML format in a DID Resolution response?

I don't want to diverge the discussion, but the XML-loving community is as big as the JSON-loving community. Anyone working with verifiable schema definitions (i.e. XSD) and data transformations (i.e. XSLT) is probably running XML-based services and wouldn't want to change it. JSON just doesn't provide the same level of tooling yet. Personally, I have two customers in that mindset. Since these are just representations of the common data model we are trying to spec out, I would argue the idea here is to be inclusive of people's needs.

[peacekeeper]

That proposal exists for Data Integrity (just add a proof to each sub-part of the response you want to have covered).

It's also reminding us that VC WG has not yet defined proof.

Once VC WG defines proof, it could make sense to register it as an extension property in the DID spec registries, which of course would also serve to show that Data Integrity can be used for other things than VCs :)

[vitorpamplona]

You could make the entire resolution response be a JWS for JSON + JSON-LD and a CWS for CBOR.

Maybe we segment the spec into Data Integrity proofs and other proof packaging needs? (Independent from the representation choice)

[OR13]

Once VC WG defines proof, it could make sense to register it as an extension property in the DID spec registries, which of course would also serve to show that Data Integrity can be used for other things than VCs :)

Assuming proof is not scoped to "only mean VCs"... 💯