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

Support OpenID4VCs in ACA-Py #2182

Open loicsikidi opened 1 year ago

loicsikidi commented 1 year ago

Hi,

First and foremost thank you for the incredible amount of works that you have done in that area 🚀 .

Do you plan to implement the full implementation of OpenID for Verifiable Credentials in a near future?

swcurran commented 1 year ago

Sorry for the slow answer. Work has started on this in Aries Framework JavaScript (see this PR 1384. We’re planning on learning from that and then seeing how OpenID4VCs fits into the Aries frameworks in general and ACA-Py specifically. We’ve been talking with the OpenID folks since the announced their protocols. We expect to learn more and discuss ideas for adding OpenID4VCs to Aries at the upcoming IIW later this month.

More to come. If you have some contributions to make in this area, please let us know.

loicsikidi commented 1 year ago

Hi,

(sorry also for the lack of velocity...).

Great news! I'll check the PR 👀 .

Anyway, I am motivated to be a contributor on this topic if the project need resources.

There is a lot of stuff to do in this area 🚀 .

steatcal commented 1 year ago

@swcurran -has there been any further discussion for support in ACA-Py. If for sure would be tremendously helpful if it was dual-stack!

swcurran commented 1 year ago

Some discussion, but no one has (AFAIK) built anything. There hasn’t been a PR. From a BC Gov perspective, we’re looking forward to seeing what happens in AFJ with the support they have added — how it gets used. And continuing on with the many other things that we’re doing :-).

swcurran commented 11 months ago

Discussed on the ACA-Pug call 2023.08.08. Noted in the call:

A possible design is to make it a companion service that calls into ACA-Py vs. within ACA-Py -- much like we do today in vc-authn-oidc. There is a requirement for additional public endpoints beyond the DIDComm endpoint, and so perhaps those could be in a separate service calling ACA-Py endpoints for preparing (SD-)JWT credentials – similar to the JSON-LD endpoints we have today – sign/verify.

Another alternative might be a – plugin, so that there can be a tighter integration for calling ACA-Py utility functions directly, but still a separation from the core features of ACA-Py.

And of course, it could also be a feature added to ACA-Py directly.