New verification material property supporting JWK sets by reference

[codeglobally]

Presently, publicKeyJwk and publicKeyMultibase are the only verification material types supported for verification methods in the specification. This is limiting for enterprise adoption where security best practice dictates frequent key rolling and hygiene, along with the broad adoption of external key management capabilities such as Azure Key Vault or the Amazon Key Management Service.

Proposal is to add a new verification material property publicKeyJwks of type URL, which is similar in behaviour to the jwks_uri property in OpenID Connect metadata.

[OR13]

see https://www.w3.org/TR/did-core/#verification-methods

Doing this without considering the larger standard would harm interoperability.

If you want to rotate keys frequently, you can use service endpoints.

See https://www.w3.org/TR/did-core/#services

For example:

{
  "service": [{
    "id":"did:example:123#ephemeral-keys",
    "type": "OpenIDConnect", 
    "serviceEndpoint": "https://example.com/.well-known/jwks.json"
  },
  {
    "id":"did:example:123#google-kms",
    "type": "EnterpriseKMS", 
    "serviceEndpoint": "https://cloudkms.googleapis.com/$discovery/rest?version=v1"
  }]
}

Just beware that an attacker doesn't need to compromise your DID if they can simply compromise an ephemeral key server you authorize and then possibly forget about.

[OR13]

Another alternative would be to define a new verification method type, here are some examples:

• https://w3c-ccg.github.io/lds-jws2020/
• https://w3c-ccg.github.io/ldp-bbs2020/
• https://w3c-ccg.github.io/lds-ed25519-2020/

But its not clear to me what "relationship" an "authorized KMS" would be acting under... see https://www.w3.org/TR/did-core/#verification-relationships ...

Perhaps some existing JWK can be used to sign ephemeral JWKs that are rotated more frequently and we can keep using normal JWKs and publicKeyJwk which is the only verification method defined for interoperability here: https://www.w3.org/TR/did-core/#verification-material that is compatible with existing JWK based suites, like OAuth.

[OR13]

cc @selfissued since we have talked many times about "non standard" verification methods, what are your thoughts on this.

[OR13]

I do think committing a decentralized identifier to an external authentication service controlled by someone other than the did controller raises questions about decentralization and security... but they can probably be addressed.

[OR13]

Another solution would be to use a VC for this, and not publish a service endpoint or verification method associated with ephemeral keys to the did verifiable data registry at all... thats probably the better security approach.

[OR13]

Or it might be better to just use a did method like did:web where updates (key rotations) are cheap, and its already centralized so there is no real "loss of decentralization" to consider.

[csuwildcat]

@OR13 signed key lists located in one's Identity Hub are a fine example of this, so I am personally supportive of the general Issue.

[kdenhartog]

I'm not a fan of supporting a set of keys or a link to a set of keys in a single verification method and instead would expect that the best method to handle this would be to assign a separate verification method object to each key. By supporting this approach it requires additional code paths in order to uniquely identify keys when we currently only have one.

[csuwildcat]

I think maybe the intent was identifying a remotely located key, which could be done via DID-relative URL, with the actual public key bytes residing in the indicated Hub location.

[csuwildcat]

I do think committing a decentralized identifier to an external authentication service controlled by someone other than the did controller raises questions about decentralization and security... but they can probably be addressed.

Doesn't mean it's not under the owner's control, especially if the paradigm is to have the remotely located key representations signed by a DID document key.

[kdenhartog]

I think maybe the intent was identifying a remotely located key, which could be done via DID-relative URL, with the actual public key bytes residing in the indicated Hub location.

Yeah I understand it's possible I'm just advocating that we shouldn't do that since it's going to make it more complicated to process and reference these keys in an interoperable way.

[csuwildcat]

@kdenhartog we'll have Hubs as a standardized DID-relative resource mechanism within the next 3-4 months, so we can make a specific reference URL format for it. Having these external references is important, as it makes architectures more perfomant and flexible.

[peacekeeper]

My first reaction to this is the same as @kdenhartog 's.. Just use separate verification methods, and update the DID document frequently. Use a DID method that makes updates cheap & easy.

If you want to host a key list "outside" the DID document at some URL, then you could also encapsulate that key downloading logic inside your DID method, and let a DID resolver do that work, instead of higher level code -> suddenly you end up with the key list "inside" the DID document, even though behind the scenes it was downloaded from some URL just like you wanted.

[peacekeeper]

signed key lists located in one's Identity Hub

Reminds me of a great discussion led by @csuwildcat at DIF ID WG a while ago: https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md#meeting---12-july-2021---1400-et-recording

[OR13]

Here is a thought…

Your did method can define resolution in terms of service endpoints… so this is a legal way to resolve a did document:

did document = resolved from blockchain data.
ephemeral or historical keys = resolved from "identity hub or service endpoint".
final did document = combination of both

The down side is your did method needs to understand how to use a “hub” or “service endpoint” to “get fresh keys”… the plus side is you don’t need to do anything to did core and your method works as expected out of the box.

If other methods are jealous they can copy your method, with no loss of generality or hit to interoperability.

[csuwildcat]

I strongly disagree with the last few comments. Verification Methods were purposefully created and articulated to include more than document-embedded public keys. There's no reason why we should force a Method to couple to other systems if users want to add Verification Methods that require some form of verification beyond reading public key bytes from the document itself.

[OR13]

A DID document can express verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interactions with the DID subject or associated parties.

https://www.w3.org/TR/did-core/#verification-methods

@csuwildcat you are correct, but implementing a verification method that is not a public key, will limit interoperability... we could have added ethereum or bitcoin addresses as verification methods, we chose to handle those as extensions after many hours of debate.

I am not sure I fully grok, what you are disagreeing with.

Are you in favor of my proposal to make the method handle this?

Are you in favor of using an extension, as we did for ethereum and bitcoin addresses?

Are you in favor of adding a new Verification Method that relies on making network requests to obtain the actual keys?

[peacekeeper]

I agree with @OR13 that you could encapsulate the "key downloading" step inside the DID method, that's also what I suggested in #811 (comment).

I also agree with @csuwildcat that verification methods can be more than just public keys; I have been interested in examples of this for some time (there was an issue about this at #57). Yes more verification methods have an impact on interoperability (just like more DID methods), but in a way I think it could also be fun/healthy for the ecosystem to be a bit more creative here. :)

[csuwildcat]

I just want to reiterate that it's a bad idea to needlessly make things Method-specific. We should avoid Method-specific document entries as much as possible, and in this case it doesn't even make sense because the suggestion can easily be implemented with a generic Verification Method process that anyone reading a DID Document from any Method would be able to resolve. For example, you could have a reference to JWK object/set in a standardized Identity Hub, or other form of standardized datastore, and all you would need to do is understand the way to use the datastore protocol. There's nothing Method-specific about that, it's about making the Verification Method itself as generic and widely understood as possible.

…

On Sun, Jan 9, 2022, 1:27 PM Markus Sabadello ***@***.***> wrote: I agree with @OR13 <https://github.com/OR13> that you could encapsulate the "key downloading" step inside the DID method, that's also what I suggested in #811 (comment) <#811 (comment)>. I also agree with @csuwildcat <https://github.com/csuwildcat> that verification methods can be more than just public keys; I have been interested in examples of this for some time (there was an issue about this at #57 <#57>). Yes more verification methods have an impact on interoperability (just like more DID methods), but in a way I think it could also be fun/healthy for the ecosystem to be a bit more creative here. :) — Reply to this email directly, view it on GitHub <#811 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAFSSZ3EVQGXT36CD2QM3UVH4V5ANCNFSM5KKBQTYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kdenhartog]

Agree with not making things method specific and rather make it well defined in the verification method object. If you want to reference a set of JWKs all under the same URL (similar to how OIDC references JWKs for verifying tokens) using the described method I think it makes sense to do this in a way that defines itself as a verification method suite (which could define the publicKeyJwks property and how to process retrieving the keys) with a new VM type property so it can be most compatibly processed like other verification method suites.

Going the path of putting these things in a service endpoint seems a bit out since it's more focused on proof of controllership of the DID which has been the purpose of verification relationships in DID Documents. Also if you do go the path of making these keys stored else where and just referenced on the DID Document can we find a way to key the public keys integrity protected so that relying parties can identify any changes like CRLs do. Even if they're no longer being stored on the VDR.

[csuwildcat]

"Also if you do go the path of making these keys stored else where and just referenced on the DID Document can we find a way to key the public keys integrity protected so that relying parties can identify any changes like CRLs do. Even if they're no longer being stored on the VDR."

The assumption with such a Verification Method would be that the key set it points to is signed as a set (or individually) with a key that is present in the DID Document, allowing you to trust that the association was intended by the DID controller. This way a user can associate N keys with their DID through a mechanism that is scalable, performant, and better attuned for many scenarios.

[kdenhartog]

Seems like a reasonable way to do it. I think we'd just need to define the verification method suite for it.

This does raise the question of if we're going to allow verification method suites to be an extension point then why did we define publicKeyMultibase and publicKeyJwk as the only properties to represent public keys? Practically speaking it does help reduce the number of code paths needed to process a key, but it also seems that we (the WG) were a bit short sighted about the value of these properties since I think it's been fairly well understood that we want to support VM suites that are not PKI based.

[peacekeeper]

why did we define publicKeyMultibase and publicKeyJwk as the only properties to represent public keys

The way I see it, just because we defined those in DID Core doesn't mean that others can't be used or invented in the future? The DID spec registries list several additional ones: https://w3c.github.io/did-spec-registries/#verification-method-properties

[kdenhartog]

Yeah I tend to agree, but I was recently looking back at the notes for what led us to select these two and it argued directly against the idea that others can be used or invented in the future since it would harm interoperability. That's what I meant by that.

[csuwildcat]

Technically something that effectively just points at JWKs is still using JWKs, so the desire for representation normalization of actual key bytes that was the basis of that decision is a bit orthogonal, and still a relevant concern. This is more about the location of key sets than their format, and we need a DID-relative object discovery mechanism anyway, so using it for this just makes sense.

[csuwildcat]

"I can do all things through Hubs who strengthen me" - Saul of Tarsus on Identity Hubs 😄

[thehenrytsai]

I am in general in favor of a verification method that looks up a key set(s) stored in an external store (Identity Hub). Even though, it is less than perfect in practice:

The whole intent of an external key set is so that frequently used logical keys can be rotated cheaply, easily, and frequently to meet "best security practices". However if a "master" key is required to be present in the DID document for signing the external key set, it begs the question if this master DID Document key itself should be rotated frequently also to follow the same "best security practice"?

Also if this private "master" DID Document key is secured in the same manner/location as the private key(s) in the external key set, it defeats the point of this master key, as an exploit that grants access to the private key(s) in the key set also grants the master key. So securing this master key independently would become a hard requirement which adds yet more cost and complexity to operating an enterprise/organizational DID controller such as a VC issuer.

Most likely a bad idea, but if the external key set is stored behind HTTPS, could this master key (thus signing) be optional? Given that the DID relative URL to the external Identity Hub would be specified in the verification method by the DID owner, trust to the Identity Hub can be assumed?

Love to hear your thoughts on the above!

[jandrieu]

I think we already support arbitrary verification methods. No change is needed to support JWK sets. Just use a context to define the terms.

[pchampin]

This was discussed during the did meeting on 2024-08-29:
https://www.w3.org/2024/08/29-did-minutes.html#t04