Relation between the did id and the issuerId in the anoncreds resources?

[TimoGlastra]

The anoncreds resources in the example contain an issuerId. Should there be some verification between the did:web and the value of issuerId?

Or should maybe the issuerId be omitted from the hosted resource, and inject by the resolver? So there's no way to spoof the issuerId of a resource?

[genaris]

I think it would be simpler to keep original object structure (including their issuerId) in the hosted resource. But I agree with you that it will be good for resolvers to do the matching between the DID resolved and the issuerId of the objects.

@PatStLouis do you remember any reason why we left this particular point open other than simplicity? BTW @TimoGlastra opened some good points for discussion here, it would be nice if you can review them!

[PatStLouis]

My PoC implementation was directly derived from the spec. issuerId is part of the schema JSON structure to be published. This was also before the recent CWU from BCGov and based on experimental anoncreds in w3c work from the time.

@TimoGlastra the schema issuer may be different than the cred def issuer. Multiple issuers could publish a cred def from a common schema published by an author as is the case with indy-based anoncreds issuance. So the relationship from the VC issuer's did and the schema author's did may or may not exist. The issuerId from the cred_def resource and the schema resource might not be the same. The VC issuer must match the cred_def issuer, the same way a VC issuer would need to match the did in control of the verification method of other cryptographic suites.

I think the verification between the did:web and the issuerId value of the schema would fall into the controllers business rules but since there's no cryptographic elements at play I wouldn't see a security issue here, maybe I'm wrong? What current verification happens on into around the did that published the schema of a credential?

{
  "issuer":"did:web:my.did.web",
  "credentialSchema": {
    "type":"AnonCredsDefinition",
    "id":"did:web:my.did.web#123,
    "schema":"did:web:some.other.did.web#123
  },
  "proof": {
    "type": "DataIntegrity",
    "cryptosuite": "anoncreds-2024",
    "verificationMethod":  "did:web:my.did.web#123"
  }
}

I'm against resolvers injecting data as this can create interop issues. This is a problem with did:indy resolvers and did:key resolvers.

If it was up to me I would get rid of the schema resource entirely and just include this information in the cred_def 🤷

[TimoGlastra]

Thanks for the input @PatStLouis.

I agree that the cred def issuer and schema issuer don't have to be the same.

The thing I'm concerned about is e.g a schema with the following content:

{
  "issuerId": "did:web:usa.gov",
  "name": "Example schema",
  "version": "0.0.1",
  "attrNames": ["name", "age", "vmax"]
}

while the schema id is: did:web:maliciousActor.com?service=anoncreds&relativeRef=/123.

There should be a relation between the schema/cred-def and the did it is linked to. With did:cheqd and did:indy this is handled by the blockchain (cheqd with did-linked resources, while for indy anoncreds support is baked into the blockchain)

I'm against resolvers injecting data as this can create interop issues. This is a problem with did:indy resolvers and did:key resolvers.

I see this more as a specification issue in that case. For did:cheqd we on purpose don't store the issuerId in the resource and inject it in the client, as the data inside a resource is not validated while we have verified the resource is linked to a did (which we know in the client) . This makes it less prone to security issues as there's only one place where you can find the value. If we were to add the issuerId to the resource, an implementation needs to check it against the did of the resource to be sure the issuerId is valid, which adds one more security check that a client needs to implement.

In the Credo implementation I now made a PR to always ensure the issuerId and the did that links to it are the same, to prevent spoofing of the issuerId value in a published schema/cred-def/rev-reg

[TimoGlastra]

Maybe it would also be interesting to look at signing of the anoncreds objects with your did:web? That way the anoncreds object is undeniably linked and published by a did?

[PatStLouis]

I see what you mean, in this case yes there should be a check for this, the issuerId value must match the did included in the resource id. I'm un-opinionated in if this should be in the resource object or not, it feels like having it present is an additional security measure that proves this schema was intended to be referenced by this ID and provides information as to where it comes from.

Signing these resources is also interesting.