Implications if serviceEndpoint is hosted on different domain than the did:web DID?

[TimoGlastra]

Usage of did:web allows the documents to be hosted on a different domain, which in theory allows me to reference anoncreds methods hosted by other did:web documents.

I'm not sure if there's any implications to this, but wanted to open an issue for it to discuss.

E.g. in did:web:animo.id we have an anoncreds service endpoint that points to 2060.io.

The issuerId will not match in this case (for which I opened an issue in #2), so that could be an "error" that must be handled by libraries? Or

I'm thinking there may be some security implications to this, but can't think of any concrete things yet

[PatStLouis]

I think we should review this did web anoncreds spec given the latest development of the anoncreds di cryptosuite work. A lot of information here is outdated and was inspired by experimental work. While it's been well received by the w3c community, I believe it can be improved.

The question you raise would first require us to define "is the issuer of the credential responsible to host the verification material". The idea of having a service hosting the verification material was to mimic the VDR model, where you could have a trusted VDR service hosting verification material for multiple issuers.

Given that in the anoncreds-2023 cryptosuite the cred_def_id is the verificationMethod value of the relevant proof, I would probably be more inclined to resolve the cred_def_id to a verificationMethod than a service, and include the multibase value of the public cred-def portion in the did document itself:

  "verificationMethod": [{
    "id": "did:web:my.did#123",   <--cred_def_id aka verificationMethod
    "type": "Multikey",
    "controller": "did:web:my.did",
    "publicKeyMultibase": "..."  <--cred_def_pub_multibase_encoded
  }]

I would let go of resolving schema id's since it brings no added value and the anoncreds-rs library is fully functional without this.

The spec reads:
The holder MAY want to retrieve the Schema and verify the consistency between the list of attributes in the Schema and in the Public Credential.

At no point in the spec resolving the schema is required/meaningful. Having the schema as an object seems more like an indy-sdk artifact than a purposeful component.

While this would require the issuer to add a verification method for every credential schema they want to issue, it makes the verification part more straightforward.

@TimoGlastra are you working on an implementation or you are just brainstorming ideas? Any input on the above?

[TimoGlastra]

I like adding the cred def to the did document. It seems like the perfect place for it!

I'm currently working on an implementation for paradym.id and the Paradym Wallet, we'll be going live with a first version next week already. But happy to adjust things where needed. We currently support AnonCreds with did:cheqd and now adding did:web to it.

One issue with adding cred def to did doc is that resolving a did doc can become more expensive if really large

[PatStLouis]

I agree it would make the did document larger.

My approach is based on the vc-api model, where you would have issuer instances pre-configured to issue 2-3 different credentials, so it would limit the amount of cred def available in the did doc. This would also favor caching did documents since it would be fairly static.

I did some experiments over the weekend with compression and encoding, I was thinking something similar to the BitstringStatusList where you compress+encode the data. I'm testing zlib/gzip/brotli + b58/b64 encoding to compress/encode the primaryValue of the cred def to a smaller size. The rest could live at the verification method level (change the issuerId to the controller value, keep the type). I'm not sure what to do with the tag. I'm thinking the schemaId could go in a credentialSchema.id field in the vc and would resolve in an external VDR (can use did web or even just https for the ID), I was also thinking using the schema name as an additional credential.type or credentialSubject.type.

I have a python fastapi implementation called fast-anoncreds I'm working on. It's an API exposing each flow of the spec. Maybe we can try to do some interop tests around this eventually? With @genaris implementation we could cover issuer/holder/verifier. I'm focusing on a w3c first approach and leveraging anoncreds as a data integrity securing mechanism.