search

hyperledger / anoncreds-spec

The specification for AnonCreds verifiable credential exchange.
https://hyperledger.github.io/anoncreds-spec/
Apache License 2.0
45 stars 24 forks source link

Should the specification require enforcement of the uniqueness of Schema name/ver and CredDef tag? #143

Closed swcurran closed 8 months ago

swcurran commented 1 year ago

In Indy, a Schema ID includes the publisher's DID, and the name and version and so the combination must be a unique. Likewise a Cred Def contains the issuer's DID, a schema ID and a tag. However, in other schemes, the IDs are contentless -- just unique identifiers. They may contain the DID of the schema publisher or issuer, but not the name/version or tag.

Question: Should the specification include a uniqueness requirement?

After a Discord discussion my feeling is it should not. It should require the IDs be unique, but not that combinations of properties within the objects unique. If a version exposes the properties in the identifier, that would enforce a uniqueness requirement on the properties.

Opening the issue to make sure there are no other side effects from making the decision either way. AFAIK, the only reason to enforce property combination uniqueness was if you were querying the ledger by the properties instead of the ID, but I don't think there is any requirement for that.

edeykholt commented 1 year ago

Why not have the ID (or another field) be the hash of the fields (concatenated) that must be unique?

rodolfomiranda commented 1 year ago

Why not have the ID (or another field) be the hash of the fields (concatenated) that must be unique?

that will put a constraint on the schemaId . Right now we are leaving it out to each method implementor.

swcurran commented 1 year ago

The idea is to not have a constraint if we don’t need it. With my Indy background, I had been thinking the constraint was needed, but I don’t think it is, and I’d just like to get confirmation about that.

As long as the participants (issuers, holders, verifiers) are always referring to a specific schemaId, all is good. Whether the creator of the schema decides to reuse properties is up to them — everyone can see that the object is different, even if certain internal properties stay the same.

swcurran commented 1 year ago

To be clarified in the spec to say these are not enforced as being unique. @swcurran to make PR.

swcurran commented 1 year ago

Discussed at 2023.03.13 call.

swcurran commented 8 months ago

I think this is resolved, but added this to the “finish checklist” #175 to verify.