search

hyperledger / aries-cloudagent-python

Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized identity applications and services running in non-mobile environments.
https://wiki.hyperledger.org/display/aries
Apache License 2.0
407 stars 511 forks source link

Add support for creating cred-defs that contain a subset of a schema's attributes #1971

Closed WadeBarnes closed 1 year ago

WadeBarnes commented 1 year ago

It is possible, with the indy-sdk at least, to create a cred-def with a subset of a referenced schema's attributes, example below. This makes the use of shared schemas cleaner for use cases when a schema contains additional attributes that are of no interest to one jurisdiction but are of interest to another. It also allows for additional use cases where different use case specific cred-defs can be generated from a single schema.

This (indy-sdk) api makes it possible:

aca-py, currently, makes the assumption the attributes of a cred-def must be the same as the referenced schema both during cred-def generation and credential issuance:

Example cred-def containing a sub-set of a schema's attributes. Note parent_1_full_name and parent_2_full_name are not included in the cred-def. image

ianco commented 1 year ago

... to create a cred-def with a subset of a referenced schema's attributes

@swcurran does the new anoncreds spec take this into account?

swcurran commented 1 year ago

While it may be possible, I don't believe the indy-sdk referenced feature is intended to be used to do what is described in the issue description. Technically, you can do it -- change the schema_json item after retrieving the schema and before creating the CredDef. However, it is not expected by anyone in the ecosystem and it is not clear how later interactions would work.

We have talked about this in some Aries Working Group and AnonCreds Specification calls in another similar context. Notably, if we were to switch to using BBS+ Signatures in AnonCreds (replacing CL-Signatures), there is no technical need for either a Schema or a CredDef as there is only one key involved -- a simple DID would suffice. The issuer could just sign some number of claims, perhaps even different on every credential. The problem with that (and to lesser extent with what is proposed in this issue) is that by making the credentials more dynamic, it is harder to write code to handle all possible scenarios and it is harder to drive "standards" for credentials. We have had general agreement on those calls that keeping both the Schema and the CredDef is a good idea. An example of this added complexity is the following. If this feature were implemented, and a proof request came in asking for 4 claims from the Schema, but the holder has been issued a credential rooted on a CredDef that has only 3 of those claims, would the wallet be able to find the credential to construct the proof? Is the proof satisfied if the holder supplies only the 3 values, and (presumably) sends an "unrevealed" for the 4th item?

If we do want to support this, it must be done across all Aries Frameworks -- not just ACA-Py. An Aries Framework created to assume (as I think most do) that a Schema and CredDef will have the same claims may blow up if an ACA-Py issuer issues a credential with a different CredDef/Schema.

While this may be a good approach, IMHO we need to think carefully about the ramifications.

ianco commented 1 year ago

2 questions for Aca-py then:

  1. Do we want to allow Cred Defs to be created with a sub-set of Schema attributes? Sounds like we're leaning towards No?
  2. Do we need to build in support for or checks against Cred Defs/Credentials that are created with a sub-set of Schema attributes? If it's "possible" then someone might do it ...
swcurran commented 1 year ago
  1. My leaning is no, but I don't represent the whole community. It should be raised at the community level if people want to do this.
  2. This is the first time I've heard of someone contemplating this so don't know if it is urgent to block in ACA-Py. I suspect things just wouldn't work for the participants-- e.g. holders/verifiers would get unexpected errors. But that is only a guess and either code analysis or experimentation would be need to know for sure.

Is there a controller Admin API endpoint for creating a CredDef that allows the user to alter the Schema JSON?

ianco commented 1 year ago

This is also the first I've heard of this capability, and I don't know if anyone has ever tried to do this or what the implications would be. There's no aca-py support for this, we only allow a cred def that fully implements a schema.

I think the new anoncreds spec should either embrace this capability or explicitly forbid it. Otherwise some other clever individual will figure out that it's possible and then run with it ... If the anoncreds spec includes this capability then we need to ensure that all the aries frameworks support it.

swcurran commented 1 year ago

I will raise it at the AnonCreds Specification call and see what the response is. My guess the group will be against this, but we'll see.

swcurran commented 1 year ago

Per the discussion within the AnonCreds Specification Working Group, this is a loop hole and we strongly recommend not using it, as it will greatly complicate the challenges faced by Holders and Verifiers in creating and verifying presentations.

See this comment for a timestamp in the recording of the discussion held by AnonCreds Spec Working Group meeting.