You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 13, 2024. It is now read-only.
Should the organization profile (and bank account) be hardcoded java classes?
Particularly, not all organizations will agree to what fields are necessary to add to their profile. The Idenitifiers list is confusing for BC Gov users.
The text was updated successfully, but these errors were encountered:
The first question is are they? Because they shouldn't. For the backend the org profile is a Verifiable Presentation.
Generally the org profile is something we built when json-ld credentials did not exist yet in aca-py as we needed a way to present more complex structures to a public audience. As aca-py now also allows json-ld credentials the plan is to refactor the public profile and this will probably need to happen in the following order.
Add support for issue-credential v2.0 api (with indy format)
Add support for present-proof v2.0 api (with indy format)
Add the possibility to configure json-ld schemas in the UI on top of the existing indy json schemas (needs a way to expose a context)
Redo the partner details page so it can handle json-ld
Add support for issue-credential v2.0 api (with json-ld payload)
Add support for present-proof v2.0 api (with json-ld as payload)
Redo the public profile so that it can be based on the self configured json-ld schema, but also allow embedded foreign VC's
If this is done users can configure their own org profile how ever they see fit, but it's a bit of work.
Great points and plan @etschelp.
This is certainly not time sensitive, so makes sense to wait until there is the v2.0 support and the move to json-ld. Mostly just putting this in the backlog as we got some feedback from UAT where users didn't know what to do with the profile and some of the fields.
If the current UX issues are only/mostly due to unknown identifiers, this would be easy to fix. The backend does not care about the actual identifiers. Currently the identifiers are set in the OrganizationalProfile.vue component and we could make this configurable.
We'd only need to update the context in order to still have valid json-ld.
Should the organization profile (and bank account) be hardcoded java classes?
Particularly, not all organizations will agree to what fields are necessary to add to their profile. The Idenitifiers list is confusing for BC Gov users.
The text was updated successfully, but these errors were encountered: