BB Interaction Flow

Owned by Steve Conrad
Last updated: Feb 16, 2023 by Ain Aaviksoo (Deactivated)
4 min read

Assumptions

  • GovStack works effectively with coordinated BBs

  • BBs should be independently interchangeable (by compatible DPGs)

  • It is not assumed or preferred that the best software solution must perform all BBs (in a closed environment)

(Draft) conclusions

Practical needs (as outputs)

  • Both governance (=How decisions are made and enforced?) and architecture (=What tech requirements have to be met?) “framework” for workflow coordination between BBs is needed

  • Such framework should be agreed across all BBs at least as

    • principles for creating-and-managing the workflows that require/assume multiple GovStack BBs - the “governance blueprint”

    • considerations and requirements for architectural decisions

      • are there “set combinations” of BB-s for specific functionalities (eg “signing a document/consent with user verification”)

      • are partial combinations of workflows allowed (=can you mix-and-match components from GovStack and outside)?

Discussions

Example scenario for BB interaction

The Consent, eSignature, and ID BB teams have created a scenario to help work out how building blocks should interact in a typical scenario:

 

Questions/issues that need to be resolved based on this scenario:

  1. When is the IM needed?
    The question needs to be addressed on two independent levels:

    1. FIRST, it is assumed that for a whole/single government approach to information management, there must be a unified security framework applied. Then, in order to deliver efficiently and effectively on such security management requirements (see also GovStack Security Managment specification) for an eGovernment framework, it makes sense to provide a universal public service together with the set of standards available to all participants of the given eGovernment ecosystem. This is a corner-stone of whole government approach to information management and should perhaps be considered before any technical considerations.

    2. SECOND, if such desire - a whole government approach to information management - does hold, then are what are the suitable alternatives to facilitate the required security features?
      IM as a concept and also a technological solution has proved to to provide this. What are the alternatives to IM that - while delivering the same technical features - maintain similar level of:

      1. easy implementability and transparency

      2. low barrier to any data service provider

      3. low complexity for any system participant to build data services with any other system participant (small or big, public or private, domestic or international, on prem or cloud-based)

  2. Structure/process and scope for workflow orchestration

  3. Do we need a service registry?

  4. AR: It is not clear from the diagram where is the private key. If the key is in the token in the user’s browser, then the diagram is okay. But if the private key is in eSign BB then when the user is signing consent, I think we can not trust the access token. After receiving the signing request eSign BB shall redirect flow to the User to authenticate the signer. This authentication will prevent attacks from “Health care service” to fake user consent.

<I failed to insert the answer in right please, so I put it outside of numbered list>

Before explaining “when IM is needed” let’s note the following snippet from the previous diagram:

 

is actually shorthand of maybe this kind of sequence:

Results of requests marked on the diagram with '*’ could be cached for some period of time.

This diagram shows that sending messages through IM is a relatively heavy operation but absolutely necessary from a security point of view. IM gives legal force to a message.

The answer is that IM is needed whenever one of the following is actual:

  • message crosses the public internet;

  • message goes from one administrative domain to another;

  • there is a need to give legal force to a message;

  • there is a need to enforce non-repudiation.

 

Meeting Notes: Feb 1, 2023

Participants: Ain, Taylor, Sasi, Aleksander, Jake, Wes, Steve

Goal: Understand and define process for resolving these core questions

  1. Do we need to have an information mediator for all BB interactions?

    1. Jaume: IM should not be a requirement for all BBs

    2. Taylor: The information mediator provides a secure transportation/exchange layer, pub/sub functionality, and an API gateway.

    3. If a BB can implement these functionalities without needing an IM, then is that an acceptable solution?

    4. Wes: Having IM as a requirement for all cross-BB communications may be too burdensome and may be a single point of failure

    5. Ain: how is security managed across all of the interactions if an IM is not used. IM as it’s implemented currently should not be a single point of failure.

    6. Taylor: IM could be articulated as ‘recommended approach’. And IM provides a service registry as well. Can receive a valid OpenAPI spec and publish as a service.

    7. If we don’t use IM, then BBs are responsible for providing secure exchange and service discovery themselves in the implementation

    8. If we are working in a local environment, then IM is not needed. If we are crossing into a different computing environment, then we do

  2. Workflow orchestration

    1. How do we manage orchestration in the above sequence? How will the user request be managed behind the scenes, as there are multiple calls that need to be made before responding to the user

    2. How does a BB know that the incoming requests are valid?

    3. How do we manage scope for a full user journey - how do we know that a request is applicable to a specific scope for a particular user request?

    4.