Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Tracked by #175
swcurran opened this issue Mar 7, 2023 · 6 comments

Comments

@swcurran
Copy link
Member

swcurran commented Mar 7, 2023

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
Copy link

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

@rodolfomiranda
Copy link
Contributor

rodolfomiranda commented Mar 7, 2023

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
Copy link
Member Author

swcurran commented Mar 7, 2023

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
Copy link
Member Author

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

@swcurran
Copy link
Member Author

Discussed at 2023.03.13 call.

@swcurran
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants