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

We can extract the schema_name and schema_version from the passed schemas in the verify_presentation method and pass them down (verify_presentation -> verify_requested_restrictions -> gather_filter_info). #34

Closed
1 task
berendsliedrecht opened this issue Dec 15, 2022 · 3 comments · Fixed by #50
Assignees

Comments

@berendsliedrecht
Copy link
Contributor

berendsliedrecht commented Dec 15, 2022

    We can extract the schema_name and schema_version from the passed schemas in the `verify_presentation` method and pass them down (`verify_presentation`  -> `verify_requested_restrictions` -> `gather_filter_info`).

For the other ones, maybe we need to look at adding an issuerId property to anoncreds objects after all? I think there's no harm in it, and it would be backwards compatible with current anoncreds (issuerId is always the indy did in that case). Relevant issue: hyperledger/anoncreds-spec#102

For the indy method it would be the indy did, for cheqd it would be the cheqd did. For non ledger based methods there must be some point of reference of who created the schema/credential definition. For https it could be the host (e.g. schema https://hyperledger.org/membershipSchema would have issuerId of https://hyperledger.org

  • support both _did and id for restrictions

@swcurran thoughts?

Originally posted by @TimoGlastra in #25 (comment)

@swcurran
Copy link
Member

An interesting question. Agree that this is relevant to Issue 102 in the Spec repo.

I think we should include it. It would also be good if we could validate it, but that gets tricky -- AnonCreds Method specific and even then, self-asserted. Would it be possible to require that all AnonCreds URIs stem from the issuerId? That would work for the existing/planned methods but would be hard to explain and enforce.

Bottom line -- I think we should include it and require it.

@berendsliedrecht
Copy link
Contributor Author

Would it be possible to require that all AnonCreds URIs stem from the issuerId?

Would it make sense to make all AnonCreds URIs come from the issuerId? If we have a cred_def with a schema_id inside from another issuer, it would fail while being valid, right? Or maybe I am misunderstanding the point.

Also, do we want to add it to the revocation_registry and revocation_registry_definition? Or is there something changed in the spec about this?

And the last question, do we require all issuerId's to be strings or a URI like the anoncreds object identifiers?

@berendsliedrecht
Copy link
Contributor Author

Okay I spoke a bit too quickly and just saw @TimoGlastra PR hyperledger/anoncreds-spec#126. Will use that as a reference.

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

Successfully merging a pull request may close this issue.

2 participants