Add Support For Linked Data Proofs

[Cahl-Dee]

This Well Known DID Configuration implementation addresses a particular need that we at Factom Inc are working to solve in a customer implementation. We appreciate all those that have put their time into publishing this specification.

Our implementation, and I can imagine that of others, will be tightly related to our Verifiable Credentials solution. In our VC solution, the credentials and presentations leverage cryptographic linked data proofs. As such, adoption of the Well Known DID Configuration hinges on our ability to leverage this infrastructure.

Specifically, we are requesting the 3 Cryptographic Linked Data proofs outlined here be supported. This includes:

• Ed25519Signature2018
• RsaSignature2018
• EcdsaSecp256k1Signature2019

cc @OR13

[OR13]

Adding support for JSON-LD based VCs would not be hard, and we (Transmute) need to do this in order to use this technology for our needs as well.

In the current spec, the JWT is an assertion of "sameness" its presence is meant to convey that that the issuer and the domain operator wish to communicate that they are the same entity.

We would need to create json-ld context file for the well-known-did-configuration.

We would define the context of "domain", "iss", "exp", or similar words...

Pretty much everything needed to do this can be found here: https://github.com/transmute-industries/vc-greeting-card

Added benefit of using JSON-LD is that the configuration file is readable without parsing a bunch of JWTs.

@csuwildcat what the best way to approach moving forward with this?

I would recommend we add a top level property to the configuration called "proofEncoding": ['JWT', 'JSON-LD']

Then we don't need to do anything new for the existing demo, and we can implement the JSON-LD version without much confusion. Thoughts?

[tplooker]

Hi @Cahl-Dee, firstly I'm a strong supporter of JSON-LD based verifiable credentials in many use cases, I think the standardised semantic vocabulary is invaluable in realising a cohesive verifiable credential ecosystem.

However I would perhaps debate the the merit of a JSON-LD based signature in the case of this specification (but I'm prepared to be convinced otherwise). The did configuration resource is intentionally designed to be a collection of very simple assertions aimed at linking decentralised identifiers to domain names and I'm unaware of what added benefits JSON-LD would bring in this instance?

The only argument I can think of that has merit is more uniform infrastructure options for implementors. For example if Im a vendor that only issues JSON-LD based verifiable credentials, I would rather not have to add support for jwt's just to implement this specification, is that the main reason for your request?

The most obvious option if we wanted to added support for JSON-LD based signatures in this specification, is to add them as a valid assertion format. However depending on the language of the specification this would have important implications for producers and consumers of did configuration resources. The options around language IMO are the following

1. A Producer of a did configuration resource can use a JWT OR JSON-LD signature based format for expressing did to domain assertions.
2. A Producer of a did configuration resource MUST represent their did to domain assertions in both JWT AND JSON-LD signature formats.
3. A Producer of a did configuration resource MUST represent their did to domain assertions in JWT format and can optionally also specify the same assertion in a JSON-LD based signature format.
4. A Producer of a did configuration resource MUST represent their did to domain assertions in JSON-LD signature format and can optionally also specify the same assertion in a JWT based signature format.

[Cahl-Dee]

Hi @tplooker, thanks for the feedback.

Im a vendor that only issues JSON-LD based verifiable credentials, I would rather not have to add support for jwt's just to implement this specification

This is exactly right. We (Factom Inc) are an organization that meets this criterion. Everything about the Well Known DID Configuration meets our (well, as a product manager, my) requirements except for the all-important re-use of existing infrastructure.

I would be surprised if we were the only organization in this boat, suggesting that you will see greater adoption of your work on this specification by supporting the same proof types that the Verifiable Credentials specification outlines.

As for language options, I'm assuming this is more so a topic for others, but my support would be for number 1. Numbers 2 and 3 fail to meet my re-use requirement as defined above.

A useful reference may be section 4.7 Proofs (Signatures) from the Verifiable Credentials Data Model specification.

[tplooker]

Great thanks for your clarification around what your preferred option would be and I do understand the strong desire to re-use infrastructure when and where we can.

I think the important implication of option 1 is that consumers of did configuration resources would then have to support verification of both JWTs and JSON-LD based assertions if that makes sense? Put another way option 1 simplifies the did configuration resource for producers by giving them optionality in choosing which is their preferred assertion format, however the infrastructure requirements increases for the consumers as they need to be able to verify a did configuration resource regardless of its assertion format.

[OR13]

Yes, and since JWTs are a valid format per the VC Data Model spec, this is really just saying "We support the VC Data Model"

https://www.w3.org/TR/vc-data-model/#json-web-token

https://www.w3.org/TR/vc-data-model/#linked-data-proofs

For the case where you intend to leverage semantic web technologies throughout your stack, this seems likely a critical feature.

[tplooker]

True but our assertion format does not currently conform to the JWT VC format, e.g the "domain" claim is at the root of the JSON object rather than inside a nested object with key "vc". Do we want the assertions in this spec to be valid verifiable credentials?

[OR13]

I think we probably do.

[tplooker]

I agree with semantic web technologies being invaluable in many instances i'm just un-aware of what added benefit other than infrastructure re-use there would be to making the assertion formats JSON-LD?

[csuwildcat]

@csuwildcat what the best way to approach moving forward with this?

I would recommend we add a top level property to the configuration called "proofEncoding": ['JWT', 'JSON-LD']

I prefer to keep the spec constrained to the simpler format, given its scope, but it isn't a hill I will die on, so whatever you all decide I can probably get behind. As far has how we could add it, I'll note that the current spec includes JWTs in the assertion object via the jwt property, thus we could create another property called vc and enable this without having to introduce sniffing of a single property's value to determine which it is. Any spec change to include this would need to make all the required modifications to specify how a VC is processed differently for whatever aspects are relevant to this use, as well as language that specifies what should happen if a user includes both types for some reason (e.g. to maximize the number of consuming verifiers who can process their assertions)

[OR13]

Its making them support the VC Data Model.

Its trivial to do, and since many in the community want to use DIDs and VCs together, should we not support a way for both semantically ambiguous and semantically unambiguous technology providers to assert sameness of a domain controlling entity and a DID controller?

If the desire is to not support semantic web, then one need only format their JWT in a correct looking, but semantically ambiguous manner, as many do with the @context field in did documents today <snark>.

For those who want to leverage Linked Data end to end, they are required to ensure that the context is valid, and that the proof is valid w.r.t. the context. For others, they can simply carry on as usual... nobody can force you to make your web page indexable <more snark>.

As its pretty much impossible to have this discussion without addressing the use of JSON-LD in both the VC Data Model and the DID Spec, I'll add my 2 cents here again.

If I want to express my intention to use JSON-LD, I should be able to do so.
If I want to express my intention to not use JSON-LD, I should be able to do so.

In this case, since we get to define the credential format, there is pretty much no reason why we would not provide clear guidance for both cases.

I believe that simply using the VC Data Model we can cleanly solve this. As is often repeated, the burden is on the JSON-LD side to define the context correctly... we can't prevent the non json-ld side from ignoring it, but we could ship a JSON Schema with it to make it super clear that you are not to add arbitrary fields to a JWT... something you could easily do right now.

We (spec authors) define this once, one side actually uses it, the other doesn't.

[OR13]

There is also a bit of following the herd here, currently the approach appears to be:

JSON-LD is used in:

• VC Data Model Spec
• DID Spec
• VC JSON Schema Spec

In pretty much all cases, we have taken the approach of the spec authors are responsible for ensuring JSON-LD is used properly, while other editors, contributors focus more on the part of the spec they care about.

I feel like thats fine to continue to do, but I do think it should be clear for people to express their intent not to use JSON-LD, just as you can tell robots off with robots.txt.

Its our job to create a spec that allows for accurate capturing of implementer intent, and that builds on existing standards, common community practice.

There are probably other companies out there that would love to use this but can't because we invented a custom JWT format instead of following the VC Data Model.

I think Well Known DID Configuration has a larger chance of success with the VC Data Model than without it.

[OR13]

After thinking about this a bit more, I think its fine to support a mix of both JWT and Linked Data Proof VCs.

Clients that can't understand linked data proofs would not support the linked dids... and vice versa.

This would be helpful since many DID Methods today appear to support Linked Data, but do not actually work with it, and companies using such DIDs have no actual way of expressing their intention to not use JSON-LD.... currently.

It would be awesome for a domain operator to be able to express their intent and mechanism for supporting Linked Data, or not, on a DID by DID basis.

[tplooker]

Im with @csuwildcat in that I lean towards the simpler option (JWT only) in this instance, however I'm also not willing to die on that hill either. If we feel that the added complexity for consumers of did configuration resources having to support verifying multiple assertion types is justified because we want the assertions to be valid vc's them I'm happy to explore that.

@selfissued @msporny perhaps you guys have opinions on this?

[csuwildcat]

If we wanted to support this, I think adding a new vc property to the assertions would be the best route. This way there's no change to the handling of the JWT variant of the signed proofs, and you could even include both if you wanted, to ensure that the maximum number of validating parties could process your linkage assertions.

[msporny]

Just commenting since @tplooker tagged me (thanks Tobias!)... I have no strong opinions, being new to the conversation. Due to the way things are going, it's looking like the ecosystem is going to have to support both JWTs and VCs given that there is no clear choice between those two yet for the SSI use cases (that sort of thing takes half a decade or more to play itself out in the market). Supporting both typically leads to a bigger tent at the expense of implementer complexity... and given the priority of constituencies, eff the implementers, all hail the users and the authors... support both. :P

... and my opinion here should be taken with a large grain of salt as we haven't looked deeply into the .well-known stuff yet.

[peacekeeper]

In the current spec, the JWT is an assertion of "sameness"

Just a quick thought that if someone wanted to go "Semantic Web all the way" here, then instead of defining a JSON-LD context for "domain", "iss", "exp", one could use the owl:sameAs property and do something like this:

{
	"@context": ["https://w3id.org/security/v1", {"owl": "http://www.w3.org/2002/07/owl#"}],
	"@id": "https://example.com/",
	"owl:sameAs": "did:btcr:123",
	"proof": {
		"type": "EcdsaSecp256k1Signature2019",
		"creator": "did:btcr:123",
		...
	}
}

Of course this makes everything more complicated, since implementers would have to support two entirely different document formats, not just two different types of proof. This isn't even a VC, it's just a single RDF statement with an LD proof on it. Therefore, consider this comment a "theoretical purity" contribution, which in Manu's priority of constituencies comes LAST after users, authors, implementors, specifiers :)

[peacekeeper]

Also, watch out for potential conflicts around the "domain" term, it has one meaning as a JWT claim in the current did-configuration spec, but it has another meaning in LD Proofs.

[awoie]

Hi @tplooker, thanks for the feedback.

Im a vendor that only issues JSON-LD based verifiable credentials, I would rather not have to add support for jwt's just to implement this specification

This is exactly right. We (Factom Inc) are an organization that meets this criterion.

Could you please elaborate the reason why not? I don't believe it is about increased complexity as JWTs are only base64url encoded payload + signatures. On the other hand, if you disagree, then introducing VCs (JWT/LD-Proofs) would add unnecessary complexity for all other implementers who are fine with the spec.

I would not object to support VCs but I'm asking the question why this is really needed? The current spec serves the purpose.

[OR13]

@awoie

https://beta.sam.gov/opp/bfd1662d1ad9c317e4afae6544abff3a/view

The solution SHALL incorporate, if appropriate to the particular use case, the following
emerging and/or mature specifications for interoperability that have been funded, tested
and/or championed by DHS:
○ Decentralized Identifiers (Standards Development Organization - World Wide Web
Consortium / W3C)
○ Verifiable Credentials (Standards Development Organization - W3C)
○ JavaScript Object Notation for Linked Data / JSON-LD (Standards Development
Organization - W3C)

Linking a DID to a well known corporate/government identifier seems an appropriate use case.

https://buyandsell.gc.ca/procurement-data/tender-notice/PW-19-00884577

Proposed solutions must:

Create User-centric Verifiable Digital Credentials able to operate on a national or global interoperable verification platform;
Protect the privacy and identity of the user at all times* (see note);
Incorporate the following emerging and/or mature specifications for interoperability that have been funded, tested and/or championed by the United States of America Department of Homeland Security:
- Decentralized Identifiers (Standards Development Organizations: World Wide Web Consortium (W3C) or Decentralized Identity Foundation)
- Verifiable Credentials (Standards Development Organization - W3C);
- JavaScript Object Notation for Linked Data / JSON-LD (Standards Development Organization - W3C)

This spec could check all 3 of DHS SVIPs listed technologies or just 1 of them.

Speaking for Transmute (seeking wider industry/government adoption of this spec), we'd prefer this spec support all 3 for parties that desire it.

By structuring the proving mechanism as VC Data Model compliant, we can ensure that verifiers need only support JWT / Linked Data Proof formats for Verifiable Credentials (requested by US and CA governments).

For the case that an organization's DIDs or VCs do not support JSON-LD, the implication is that their DIDs / VCs might be less likely to be accepted by governments / enterprise systems that require it.

That doesn't mean they can't use JWS / JOSE for their own purposes, or to borrow language:

if appropriate to the particular use case.

[awoie]

@OR13 I don't understand the argument as probably not every single component in the DHS system has to use these technologies and even if they have to, then this spec as it is would still include DIDs which addresses your DHS requirement. Again, I won't object as I believe we should experiment but I personally still don't see any good reason to increase the complexity of the spec.

[peacekeeper]

I agree with @awoie that in order to satisfy the DHS project requirements, probably not every single part needs to be in JSON-LD. But at the same time I can also understand the desire from an implementer's perspective to have the same data model and proof format on all layers of a stack instead of mixing different ones.

[Cahl-Dee]

Sorry for the delay, I have been OOO and up against a tight deadline. A dangerous mixture 😅

@awoie Being on the product side of things, my focus will always be delivering the most value with the least complexity possible. This is important for both internal stakeholders (code maintenance, training, internal tooling, etc) as well as external stakeholders (comprehension, implementation effort, etc).

As such, it's important to me that all proofs generated by our Digital Identity products are of the same format. Yes, we will eventually need to add the ability to verify JWT proofs but that doesn't justify adding complexity to what our products produce.

[awoie]

@Cahl-Dee That argument can also be made by the community who only wants to support JWT ;) . However, I'm ok with supporting VCs or more specifically LD-Proofs for the reason outlined above.

[Cahl-Dee]

@awoie I absolutely agree! Either group could appropriately make the argument and therefore the spec should allow for either, in my opinion :-)

[csuwildcat]

The issue with this is that the addition of assertion variant optionality forces new data format and toolchain on the overwhelming majority of entities in the industry. The outcome will almost surely be a net reduction in the number of peers who will select to support write/read of the same variant of the assertion, which will degrade effective interop. The vast majority of companies already use basic signed JWTs, so asking that vast majority to adopt a new format/toolchain is concerning, and I'd rather avoid it.

[OR13]

I have added some tests related to this here: #27

[awoie]

@OR13 @Cahl-Dee @csuwildcat @tplooker What if we make the JWT mandatory but have VCs (LD-Proofs or JWT) as optional. Conceptually, you could use .well-known without VCs. If someone wants to use that protocol they would then have to create the JWT/VC (LD-Proof) and put both under the domain and can decide to only check the LD-Proof VC. Same for JWTs. Does that make sense?

[csuwildcat]

I'm not following. Why, in the simple case of proving a signature over a signed string, can we not settle on one thing that is the most widely accepted. Notice I didn't say what the thing is, because I don't actually care about these silly format holy wars.

This is not for you, Oliver, but I have to be blunt and honest with some of the folks on this thread: we bent over backwards to seek feedback at public events these folks were at and openly asked for feedback via social media, newsletters, and other venues, yet here we are, a year after this simple, tiny spec was written, hearing this for the first time. While I don't really care much either way about the proposed modifications, you're asking for a significant, breaking change immediately after we completed work; that is deeply frustrating, and may just be unacceptable at this point, we'll see. Either way this goes, let it be a lesson to pay attention, show up, and provide feedback in a timely manner, because the only reason this change may not happen lies squarely with the folks who didn't care enough to participate.

[OR13]

We did our best to build a spec for a critical concept in our ecosystem "Linking Trusted Corporate and Government Identifiers to DIDs"

If this were truly a breaking change for major companies in the wild, we would have 0 chance of further improving it. We are lucky thats not the case, and there is AFAIK 0 adoption of the spec in its current form... thats about to change, thats the reason we are having this discussion, its a good thing.

I'm pretty used to being able to push breaking changes, in fact, I would never use a system that I didn't have a way to push a breaking change to... It should get harder to push a breaking change, as the number of people impacted goes up.... Conversely, it should be trivial to provide breaking change improvements to something that nobody is using.

We need a larger pool of more conservative interested parties, who will try their best to kill everything we create. Only after surviving such a painful trial by fire can we have higher confidence that we "got it right" and even then, if there is no way to fix what we have created in the SDO, then its not an SDO I want to support... Nothing is constructed correctly the first time, and true strength (and security) is a function of surviving a dedicated and interested opposition over time.

Here are my recommendations for moving forward:

1. We define a single credential format, for use with the VC Data Model.
2. We support all the proof formats in the VC Data Model (Big tent approach)
3. We define the behavior of verification under the model of both proof formats.
4. We let the market / god decide which VC Data Model proof format will succeed.

If you don't want to support Linked Data Proofs, don't trust DIDs that are anchored to a corporate domain with them.

If you don't want to support JWT Proofs, don't trust DIDs that are anchored to a corporate domain with them.

When 90% of the market has picked a format for this stuff, we can and SHOULD mark the loosing side as deprecated. I'm eager for this to happen as soon as possible, but I'm not CTO of Amazon, Google, IBM, Intel or Microsoft :) The sooner the big guys pick a side publicly, the better for all of us.

On the DID WG call today, the 2 use cases for DIDs that I heard were VCs and IoT.

If we build Well Known DID Configuration correctly, it can support both use cases... which will increase its chance of adoption, as well as their chance of adoption.

I have spent a lot of time building "custom crypto" and its 100% a terrible idea. If there was a better standard for credential formats that work with DIDs other than the VC Data Model, I would be jumping up and down to get us to use it instead.

I see this as a way of tying an merging standard in the DIF to a W3C Recommendation... creating a valuable form of credential which can be constructed with libraries developed by DIF Companies like UPort, Bloom, Workday, Evernym, etc...

Having this spec built on the VC Data Model gives everyone who is developing a DID Method, a way of showing how their DID Method can be used in todays ecosystem, and tomorrow's world of verifiable credentials.

When we wrote our blog post about this work, we noted that it was in an early stage: https://medium.com/transmute-techtalk/trusted-corporate-identity-fdc8260f3ad1

This is still an early proposal, and we are seeking feedback. We’re taking a similar approach to the method used by Let’s Encrypt, but we’re able to leverage the DPKI infrastructure provided by DIDs.

We wrote the blog post to try and gather additional feedback. We published the blog post December 23rd 2019.... Commit history for this repo doesn't show an official version release.

The most recent tweet from DIF I can find about it is: https://twitter.com/DecentralizedID/status/1177273953116508160

I think we can safely make improvements :)

[csuwildcat]

After thinking about this, it feels like there are two options, which I hope work for folks like @Cahl-Dee (I sympathize with your desire for having your preferred format):

1. We are able to transition to a JWT-VC that still validates as a JWT would with little to no spec modification. (@OR13, I'll let you comment)
2. We do what @awoie said and make the existing JWT mandatory, but allow some flavor of VC as optional for both writers/readers.

Can folks here get on board with this compromise, given we're now post-completion of the spec?

[Cahl-Dee]

@csuwildcat I do sympathize with the resistance to making changes to something right after getting it out in the wild. Bad timing on my part of bringing this up. I appreciate you (and others) entertaining the discussion.

In the first option you list, you indicate a willingness to transition to VC's. In this scenario, implementers should simply rely on their VC infrastructure, namely, the Verifier API.

Assuming this is the case, we could all issue the credentials with our preferred proof types while supporting verification of all the proof formats in the VC Data Model.

[OR13]

@csuwildcat You may also want to review this thread: w3c/did-core#131

The VC JWT format has a number of issues, which leads me to want to support both proof formats.

[awoie]

@csuwildcat You may also want to review this thread: w3c/did-core#131

The VC JWT format has a number of issues, which leads me to want to support both proof formats.

@OR13 Can you please elaborate "number of issues"?

For JWTs, we need to define a convention for kid, yes which is similar to verificationMethod in LD-Proofs. However, key discovery is out-of-scope of the W3C VC spec. In the same way as key discovery is out-of-scope of the W3C VC spec for LD-Proofs. This issue was discussed in Authentication WG calls. We agreed to use the DID URL convention for kid.

Note, the LD-Proof spec as per https://w3c-dvcg.github.io/ld-signatures/ does not even define the property verificationMethod which I believe is used for key discovery in LD-Proof-based implementations to verify W3C VC proof attributes. Am I missing something?

Updated:
I also believe that this should not be part of the W3C VC spec but rather in specs sitting on top such as the .well-known spec. This means, we should define in the .well-known spec how we want to do key discovery. I would however suggest to use the same approach as the SIOP DID Spec which is a DID URL for kid.

Updated:
I also see your point to allow people to use kid as the JWK thumbprint. In that case we should register a new IANA header name such as did_verification_method to have the equivalent to verificationMethod in LD-Proofs. Then, we have to use that convention also in the SIOP DID spec and we should create an issue there. Even in that case, the .well-known spec will have to talk about how did_verification_method is used and that this is a mandatory header.

Updated:
As cross-posted in the linked w3c/did-core#131, I'm open to both approaches. Let's just pick one and the problem is solved. As the W3C VC WG is in maintenance mode, we could update then the "Implementation Guide" to explain how we want to do key discovery for JWTs using DIDs.

[OR13]

1. Restricting Keys

How do I restrict the set of keys that can be used to create a VC JWT? (assertionMethod is used in Linked Data Proofs)... I can't use "use" if the key is not encoded as a JWK: https://tools.ietf.org/html/rfc7517#appendix-A.1

What is the relation to authentication, capabilityInvocation etc... these are proof purposes in JSON-LD world, but its not obvious how to map that to JWTs.

2. Canonicalization

https://tools.ietf.org/html/rfc7515#section-7.2.1

The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url-encoded JSON object.)

     {"iss":"joe",
      "exp":1300819380,
      "http://example.com/is_root":true}

https://www.npmjs.com/package/canonicalize

JSON canonicalize function. Creates crypto safe predictable canocalization of JSON as defined by draft-rundgren-json-canonicalization-scheme

So is it ok that I can change the order of iss, and exp, add whitespace and sign the same object and get a different credential (by content)? What happens when the payload of a credential is dynamically constructed in different languages?

See this thread: https://github.com/matrix-org/matrix-doc/issues/1013

And also: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-16#appendix-D

The latter has to do with how big numbers are represented in json, something which is fundamental to blockchains... bottom line is things like this exist:

https://github.com/haochi/json-stable-stringify-python
https://github.com/kikobeats/json-stringify-deterministic

Because different libraries will convert objects to json differently... yielding different hashes, and different signatures...

Linked Data Proofs use the unencoded payload option, and pass the hash of the canonicalized representation to the signing algorithm... this sidesteps these serialization issues, with the extra cost of needing to understand canonicalization... and linked data formats.

[awoie]

How do I restrict the set of keys that can be used to create a VC JWT? (assertionMethod is used in Linked Data Proofs)... I can't use "use" if the key is not encoded as a JWK:

I think, the only question that is relevant is how do you determine whether you can trust the signature of the JWT, e.g., key from the authentication section in the DID Doc was used, and that is topic of the whole kid vs custom did_verification_method discussion. The answer is it is possible, we just have to agree on a convention.

So is it ok that I can change the order of iss, and exp, add whitespace and sign the same object and get a different credential (by content)? What happens when the payload of a credential is dynamically constructed in different languages?

Yes, you would receive a different credential. I don't see any practical implications with that. An application will probably treat them as equivalent. A JWT parser would probably just look at the included claims and ignore the order anyways.

[OR13]

Sidetree treats them as different DIDS... IPFS gives them different hashes...

There are authentication, assertionMethod, authorization, etc... each of these might contain a key, or point to a key by id...

I would expect assertionMethod to be used the same way it is for Linked Data Proofs, but I don't believe it is.

Non the less, these things are all WIP.

Which is problematic for us trying to build on top of them.

I still think its valuable for us to solve this well known did configuration issue for both cases, and help strengthen both proof formats. I'm just expressing my preferred format, but I've already added tests for using JWT-VC with well known did configuration.

[awoie]

Sidetree treats them as different DIDS... IPFS gives them different hashes...

Sorry, I was talking about VCs only. If sidetree uses JWS and uses the hash/signature to uniquely identify data, then sidetree would probably have defined their canonicalisation algorithm to allow different implementations to be interoperable. But I don't want to go down this rabbit hole.

IMO, the DID specification should have language for the different proof purposes, e.g., authentication, assertionMethod (IMO, this should be renamed but I know that this is not possible for interop with the LD-Proof spec which is btw. not final yet--so there is a chance to have a better naming convention), authorization etc. I don't think it is sufficient to delegate that to the LD-Proof spec only. Especially, because some people might not want to use DIDs with LD-Proofs, e.g., LD-Signatures ;) . That also ties into the whole JSON-LD vs JSON DID Doc discussion, so this will come up at the DID WG F2F in Amsterdam next week.

I'm fine with using whatever convention for VCs, e.g., assertionMethod. That is also true for this spec. Looking at https://uniresolver.io/ and testing various example DIDs, I don't see any DID method except did:key (which was recently updated) returning DID Docs with assertionMethod. The reason might be that DID method authors are not aware of this convention. One reason more to have that included in the DID Core spec rather than in the LD-Proof spec only.

I agree with you that all these things are WIP which is problematic for us :) .

[OR13]

did:elem, did:github support all the same properties as did:key, and did:v1... but of course the spec doesn't have language to help others follow suite.

We need to get the did core spec caught up with its linked data context.... really badly.

[OR13]

Blocked by w3c/did-core#156

[csuwildcat]

It has now been 3 months since this issue was opened arguing for LD VC support, which we froze finalization and publishing of the spec to accommodate. Since that decision was made, no one has cared enough to do a PR to add that support. We need a PR asap, or we're just going to have to go with it as-is, because people are starting to blame DIF for this not being finished, and that's not cool.

[OR13]

implemented