Some questions about implementation: URIs and verificationMethod

[fabrii]

Hi! I don't know if this is the proper place for this kind of question. If it isn't please let me know.

I have some questions related to the implementation of the W3C Verificable Credentials Model.
There are many attributes of a VC that can be described as URIs. Some containing an external URI or just a plain ID. For example: credential id, issuer, verification method. Throughout the post I will make some statements, and I would really appreciate if you could tell me if I am right or wrong.

Issuer

The value of the issuer property MUST be either a URI or an object containing an id property. It is RECOMMENDED that the URI in the issuer or its id be one which, if dereferenced, results in a document containing machine-readable information about the issuer that can be used to verify the information expressed in the credential.

Option a) "issuer": "https://example.edu/issuers/14"

In this case, the issuer is a URL that can be exposed by the central registry. In my case this could be something like https://registryA/api/issuers/14. What happens if in the future the url changes, and now the service is exposed in "registryB"? If im not wrong, this cannot be changed, since the credentials already issued would point to a non-existent issuer. This is similar to the @context url. Once it is defined, cannot be changed.

Option b) "issuer": {
"id": "14",
"name": "Example University"
}

In this case, the issuer is identified by a plain ID. The verifier should know the base url of the registry beforehand if wants to know more about the issuer. The verifiers can know the central registry urls so this is reasonable. I believe it has a bit more flexibility, as the base url can change. On the other way, if the base url of the registry is the same used to expose the @context, it cannot be changed, so the benefit is lost.

Credential ID

The value of the id property MUST be a single URI. It is RECOMMENDED that the URI in the id be one which, if dereferenced, results in a document containing machine-readable information about the id.

a) "id": "http://example.edu/credentials/3732"

In this case, the credential URL must be exposed by the issuer, and not by the central registry. It makes no sense for the identifier to be a plain id since the verifiers have no way of knowing the url (as the issuers can be many). This base URL has to be fixed, and cannot change (same as issuer option A).

verificationMethod

The verificationMethod property specifies, for example, the public key that can be used to verify the digital signature. Dereferencing a public key URL reveals information about the controller of the key, which can be checked against the issuer of the credential.

a) "verificationMethod": "did: key:z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp#z6MkiTBz1ymuepAQ4HEHYSF1H8quG5GLVVQR3djdX3mDooWp"

The did:key method should be used by Wallets (for example when signing verifiable presentations). In this case, the subject (did:key) is going to be the same as the verificationMethod. Wallets should have only one key, so it is a good approach.

b) "verificationMethod": "https://example.edu/issuers/565049#key-1"

In this case, the verificationMethod is a URL that can be exposed by the central registry. In my case this could be something like https://registry/api/issuers/14/keys/1. Again, this URL is fixed and cannot change in the future.
I'm trying to understand the benefits of this URL approach differs from the did:key method. I have read that it might be related to the fact that issuers can have many keys, and they must support key rotation, in comparison to wallets that dont need it.

Thank you!

[brentzundel]

The working repository for the Verifiable Credentials Data Model is elsewhere. I will transfer this issue to that repository.

[OR13]

Seems related to several other open issues:

• About the optionality of the "kid" field in JWT-formatted VCs/VPs vc-jose-cose#31
• Accept or Dismiss the guidance provided by DIF on kid / iss vc-jose-cose#30

See also, DIDs vs DID URLs

and controller vs verificationMethod.

in did core:

https://www.w3.org/TR/did-core/

[OR13]

Let us know if these answer the questions you have, and if we can close this issue.

[fabrii]

Hi @OR13. The links do not answer the questions/statements provided above (or may be I dont understand them).

[OR13]

It seems like you might be asking implementation / vendor specific questions here.

In general identifier need to dereference to documents.... How that happens for HTTP, DIDs, Data Integrity Proofs or JWTs is not really a focus on this repository or the core data model.

I suggest reviewing interop test suites, such as:

• https://github.com/w3c-ccg/traceability-interop
• https://github.com/decentralized-identity/JWS-Test-Suite
• https://github.com/w3c-ccg/di-ed25519-test-suite