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
401 stars 501 forks source link

Question around interoperability of identity credentials #2911

Open ff137 opened 2 months ago

ff137 commented 2 months ago

Good day,

Let's say we are interested in defining credential schemas for things such as passports, ID cards and driver's licenses -- these are fairly standard, global documents.

Do you know of existing, open work that's been done for defining such schemas in a technical, standardised and interoperable way?

I imagine there must be, but it's difficult to trace down the specifications that are more technical than conceptual.

E.g. I'm hoping to be able to answer questions like which of [surname, last name, family name] is the correct, interoperable attribute name to use in an identity credential ... Or dob vs date of birth, etc.

The goal is of course interoperability, but also to avoid cases where a proof request is seeking an attribute "surname", but a holder only has credentials referencing "last name". It would also be great to understand what can be done in such scenarios. (I presume a proof request should just be re-engaged, with verifier asking for the correct attribute name instead.)

The question is primarily around indy schemas, as that's what we currently have implemented, but understanding the differences between indy, json-ld and anoncreds in this context would be great too!

Any technical references will be much appreciated! Thanks for your time. I know it's not specific to ACA-Py, so please feel free to redirect me to relevant repo or discussion forum.

swcurran commented 2 months ago

BC and other provinces in Canada developed a “Person” credential schema a year or so back. In doing that work, we investigated several other comparable schemas, including ISO mDL. @krobinsonca — can you point out where that information can be found? I also tried to tag David Bigsby on this, but couldn’t find his github ID.

swcurran commented 2 months ago

Regards this:

The question is primarily around indy schemas, as that's what we currently have implemented, but understanding the differences between indy, json-ld and anoncreds in this context would be great too!

The person credential used by BC can be seen here: https://candyscan.idlab.org/tx/CANDY_PROD/domain/13 The Credential Definition is here: https://candyscan.idlab.org/tx/CANDY_PROD/domain/14

We’re doing work on AnonCreds, Credo-TS and ACA-Py to make AnonCreds VCs align with the W3C Verifiable Credentials Data Model (VCDM) standard, so that you can use JSON-LD with AnonCreds.

ff137 commented 1 month ago

Thanks for the feedback! Those schemas are indeed helpful to see.

I wanted to reply sooner with more practical question, in particular to ask what's the "happy path" flow for when a holder has a credential with a "surname" attribute, but a verifier is seeking "last name". I wanted to do some testing first, so that I'm more informed about how proof restrictions can be used, or how multiple attributes can be requested, to accommodate this. But yeah, just wanted to mention that was one of the remaining questions. Will post again once I've done some tests for that

PatStLouis commented 1 month ago

The DHS is recommending the Citizenship vocabulary for identity credential claims. For better interoperability I would use terms from this vocabulary within anoncreds schemas. Something that will likely cause issues is the snake_case vs camelCase distinction for key names. Then again the mDL specification does mandate a specific set of attributes which isn't aligned (or doesn't take into consideration) this requirement.

I think the true question is until which point do we need to account for this 'interoperability'. Aiming for interoperability across the board from the start does have a inertia effect and prevents innovation, for a theoretical use case that might never need to happen.

PatStLouis commented 2 weeks ago

@ff137 what action can we take to close this issue? Did you get answers to your questions?

ff137 commented 2 weeks ago

@PatStLouis I'll try write a test over the next week or so. It's mainly still to understand the intended flows in cases where a holder e.g. has a credential with a "surname" attribute, but the verifier is asking for "lastName". So, what's the optimal "happy path" for a holder to notify the verifier that they don't have X, but they do have Y. I still have to go through the due diligence of testing things myself, so if I get an example flow to work smoothly, then I'll post it here to help anyone with similar questions.

PatStLouis commented 2 weeks ago

This sounds more like a negotiation protocol than interoperability. What is more likely a good idea here is for the holder to say, I don't have a lastName but I have a surname and for the verifier to recreate a presentation request. However presentation requests are based on a specific schema so the verifier would already know what attributes are present. Could we timebox this issue and close it after a week or 2 if no tangible actions can address it?

Is your use case based on the anoncreds cryptosuite or eddsa?

PatStLouis commented 2 weeks ago

Also OCA bundles could likely be used for this, an attribute mapping overlay could be defined.