Traction v0.2 - HackMD

# Traction v0.2 ## Goal of Traction Traction is intended to simplify and support common enterprise verifiable credential operations. ### Features of Traction - Tenant Management, known as the 'innkeeper', - and UI - Presentation Request Templates - Credential Issuance History - Additional metadata extending aca-py objects (list tags, comments, external_ref_id) - UI focused on - configuration and - 'one-time' operations, - support for inspecting data - and basic taking actions (present proof, accept offered credential, view creds) - Simple Event driven workflows ('On new connection, send configured presentation request') ### How does Traction work today (v0.1) The implementation of Traction that exists today (Sept 2022) behaves as an abstraction layer that fully encapsulates the Hyperledger Aries Cloud Agent (ACA-py). Consumers of traction only interact with the API endpoints defined by Traction, which are tailored specifically for that audience of consumers. ### Upcoming Changes in Traction (v0.2) Traction v0.2 plans to accomplish the same goals, in a more maintainable, interchangable, and co-operative approach with ACA-py's existing community. ### Delivery of Traction Goals in v0.2 Traction v0.2 hopes to be a suite of modular features which will improve the usability of ACA-py's native features, and present traction features side-by-side with ACA-py's existing functionality. These modules can be used independantly, allowing for the extension of ACA-py's service, not an abstraction of it. The traction team also plans to develop frontends to present ACA-py, and the suite of traction tools, in a cohesive user experience. ### Benefits of this new delivery architecture - Portability of integrations between ACA-py and Traction Existing consumers to ACA-py or Traction cannot easliy transition to the other, even though they are very simliar in their underlying goals of facilitating verifiable credential exchanges. - Independancy of features The features described above will be used together to accomplish our goal, however other members of the open source community may wish to take advantage of one, or a few, of the features above. Making our features independantly deployable will be a much better contribution the community, than a single 'walled garden' platform. - Terminology Clarity To not confuse traction with ACA-py and provide more business centric terminology, Traction 0.1 changes many terms used by ACA-py. This may be helpful for the on-boarding of new users; however it obscures common terminology in favour of unique ones, making our product less interchangable with other verifiable credential technologies. - Maintenance Effort As ACA-py changes, users of traction v0.1 would be forced to wait until traction absorbs that change, and makes any adjustments to maintain functionality, taking time and effort. Similar to android updates needing refinements and tweaks by each individual phone maker. A new architechture means smaller, faster changes to stay compatible with new ACA-py versions as they are released. ### Usage of v0.1 Traction Usage is limited to using traction endpoints only, it is the only accessed through the traction api, which provides more functionality for fewer steps in ### Risks/Unknowns - Learning curve / limitations - Horizontal Scaling for perforant heavy plugins ### Innkeeper UI Questions - wallet_key management - Disable existing endpoints in favor of 'traction' ones when needed (intercept/blocking existing behaviour, controlling who can be an issuer) ## Use Cases ### U1: OIDC IDP (Open ID Connect Identity Provider) What is the issue/pain point with vc-authn project (https://github.com/bcgov/vc-authn-oidc)? - Authentication with VC - Setup config for OIDC instance - Small UI - Small DB ## Possible Module Breakdown ### M0: traction_base - Host traction module database(s) - Track installed module to report config to TenantUI #### Usage Not visible to consumers/users ### M1: Innkeeper - Unique UI - Remove ACA-py 'multitenancy' endpoints - Allow innkeeper/host to control issuance authorizations of tenants - Small api - DB #### Usage New Module Specific endpoints and behaviour Distrupt existing aca-py `multi-tenancy` endpoints ### M2: Tenant UI - ACA-py native features - Traction module behaviour per installed module - NO DB #### Usage New Web URL for M@ to be served and interacted. ### M3: Credential Issuance History - No UI (just GET) - No API (just listen for events) - DB #### Usage New endpoints to GET data No changes over ACA-py Credential Exchange endpoints ### M4: Presentation Request Templates - Complex but focused UX - small api - DB #### Usage New endpoints to CRUD Presentation Request Templates (PRT) New endpoint to issue a credential using a PRT ### M5: LOB Metadata - UI Component - API's to edit Metadata - DB #### Usage UNSURE 1) Modify or fully replace existing ACA-py endpoints to update traction in 2) Add endpoints specifically for managing the additional metadata that is separate from the endpoints/behaviour of the ACA-py native endpoints.