Enhance Security Document Loader

[fabrii]

Hello!

I would like to explore the possibility of enhancing the Security Document Loader to support additional use cases.

I understand that in the Learner Credential Wallet, did:key is currently used for holders and issuers. For that reason, the DID resolver for did:key is sufficient.

I am picturing some other scenarios where:

1. The issuer ID is an https domain, which the wallet trusts. In this case, the issuer may decide to publish the keys in a JWKS endpoint. For reference, see jwt-vc-issuer-metadata. The Document Loader could be capable of processing a verification method like https://issuerdomain#key1 and retrieving the keys from the JWKS endpoint.
2. The issuer ID is an OID, such as urn:oid:2.16.858.0.0.0.3.0. In this scenario, we could configure the loader to recognize that all OIDs starting with 2.16.858 have keys published on a specific domain. . The loader could use this information to process a verificationMethod like urn:oid:2.16.858.0.0.0.3.0#key1, and use it to fetch the keys from the jwks endpoint.

What are your thoughts on this?

Thank you

EDIT: I just realized that case (1) might be covered by the did:web implementation.

EDIT2: I can contribute with a PR.

[fabrii]

I found also this https://github.com/quartzjer/did-jwk/, that might be relevant.

@dmitrizagidulin for guidance :)

[alexfigtree]

@fabrii Tell us more about your use case(s)? What made you consider this when creating this issue? We'd love to learn more.

[fabrii]

Hi @alexfigtree.

In our case, we would like to have unique issuer identifiers that remain consistent over time (we cannot do that with did:key). Additionally, we need to support key rotation, so we considered exposing a JWKS endpoint. This JWKS endpoint could be exposed at either the central registry or the issuer. Since we couldn’t find a DID key resolver that works with JWKS endpoints, we are considering implementing one ourselves. I could not find any specification of this.

Initially, we thought about using a domain name as the issuer identifier (e.g., https://userdomain.com/). With this approach, our central registry could maintain a list of all trusted issuer domains. If we trust an issuer's domain, we can also trust the JWKS endpoint it exposes. This approach is aligned with the concept outlined in https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-05.html#name-jwt-vc-issuer-metadata (I know this is not for W3C credentials, but the idea is similar).

However, this approach presents some potential issues:

1. What if the issuer's domain changes? Redirects might be a solution.
2. What if the issuer does not have a fixed domain?

Given these considerations, we were also exploring the use of OIDs. Each issuer in our case is assigned a unique OID by ISO & ITU-T (ISO/IEC 8824-1 Information Technology - Abstract Syntax Notation One (ASN.1)). These OIDs are unique (in the entire world) and stable over time, providing a consistent issuer identifier. However, we currently lack a DID resolver for these OIDs. The first digits of an OID can identify a central registry that belongs to a country, so it could be used to fetch public keys that belong to issuers of that country.

Example:

Issuer 1 = 2.16.858.0.0.0.3.1
Issuer 2 = 2.16.858.0.0.0.3.2
Issuer 3 = 2.16.858.0.0.0.3.3

All these issuers belong to central registry = 2.16.858, with the url "https://centralregistry.com". If our credential verification method is urn:oid:2.16.858.0.0.0.3.0#1", we can use that information to fetch the #1 key of the 2.16.858.0.0.0.3.0 issuer from the registry.

We haven’t seen this OID idea referenced in any specifications, and we assume it wouldn’t be interoperable with wallets. For this reason, we’re likely going to discard this approach.

So, the only option we have left, is to find a "jwks" endpoint DID resolver, which I think is going to be a bit more accepted in the future. We can see here that this is being implemented for SDJWT. I thought that in W3C world we could have something similar. May be this topic is better suited for W3C GitHub.

Let me know if this is clear or if you need any other information.

Thank you!

[dmitrizagidulin]

@fabrii Makes sense, thanks for the added clarification.

It sounds like you want to address the shortcomings of the did:key method, which makes sense. So, couple of questions:

1. It might make sense for you to propose an OID-specific DID Method, and add it to the DID Methods Registry ?
2. Would the Trusted DID Web Method address your concerns? (In terms of changing the domain name, it has provisions for migrating via alsoKnownAs etc).

[fabrii]

Hi @dmitrizagidulin

1. I will discuss this further with my team. If we decide to proceed with this approach, do you have a link to the process we should follow? The Decentralized Identifier Extensions link is not working.
2. Nice! I didn’t know about it. I will look into it.

Thank you for your help. You can close this issue.

[fabrii]

As a follow-up, we’ve decided to proceed with the did:web approach. Thank you