You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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 fordid:key
is sufficient.I am picturing some other scenarios where:
https://issuerdomain#key1
and retrieving the keys from the JWKS endpoint.urn:oid:2.16.858.0.0.0.3.0
. In this scenario, we could configure the loader to recognize that all OIDs starting with2.16.858
have keys published on a specific domain. . The loader could use this information to process a verificationMethod likeurn: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.
The text was updated successfully, but these errors were encountered: