Contents

1. Introduction

In the execution of evidence exchange, for a variety of reasons there may be variations in the flows that may occur. This section aims to provide an overview of the main flow variation categories and to illustrate this using some sample flows.

All content in this section is informative. It does not cover all potential flows,  In many flows, at some step, more than one alternative action is possible. The choice between such alternatives may be dependent on policy, system limitations or other factors.

Regular process variations include:

  • Whether or not the procedure requires preview.
  • Whether or not re-authentication is needed on the side of the evidence provider.
  • Whether there is 0, 1 or more than one piece of evidence of the requested type for the user.
  • Whether the evidence is structured or unstructured
  • Degree to which the identity attributes in the request allow to determine whether there may be pieces of evidence for the request.
  • For a structured piece of evidence, if it conforms to an OOTS data model or is another structured piece of evidence.

Error situations could emerge in either of the two request-response loops due to the reasons including the following:

  • Any of the eDelivery messages may fail due to technical reasons (e.g. an Access Point is down).
  • There may be errors or timeouts in connections between Access Points and Portal,  or between Access Points and Data Service.
  • There may be errors or timeouts in connections between the Data Service (a component that handles the OOTS interface) and the base registry or other source from which the evidence is obtained. 
  • Responses may not be returned, or not returned in time.
  • The Data Service may categorize error situations differently (e.g. use a generic or more specific error)
  • The user may stop interacting (e.g. Internet connection is down,   browser window closed by mistake, or some interruption).
  • The user may not be able to authenticate on the evidence provider side.
  • There may be mismatches in identity attribute values between the two requests
  • There may be mismatches in identity attribute values between the first (included in request) and second (in preview area) authentication.
  • Expected dependencies or synchronizations may not apply. For example, the second loop evidence request may be issued,  but the user does not visit the preview area or vice versa.

The source of all diagrams is in https://code.europa.eu/oots/tdd/tdd_chapters/-/tree/master/spec_diagrams/ch4/flows. 

The content in this section is preliminary and incomplete. It is provided as a first pass.

2. Data Service,  first loop error flows

2.1 Error in connection to base registry

This flow shows a scenario in which an evidence request is successfully created, exchanged using eDelivery and delivered to the Data Service. In this diagram, the assumption is that the Data Service does not manage the evidence data itself but is a facade for one or more base registries. In the connection to such a base registry, an error may occur. The Data Service constructs a QueryException response which it sends back to the requester.  

2.2 Timeout in connection to base registry

This flow shows a scenario in which an evidence request is successfully created, exchanged using eDelivery and delivered to the Data Service. In this diagram, the assumption is that the Data Service does not manage the evidence data itself but is a facade for one or more base registries. In the connection to such a base registry, a timeout may occur. The Data Service constructs a TimeoutException response which it sends back to the requester.  

3. Online Procedure Portal

3.1. Response that cannot be correlated

In the scenario, a data service constructs and returns an evidence response to a particular evidence requester. Since there may be multiple users in the portal using OOTS, responses must be correlated to the requests they relate to, so that pieces of evidence are linked to the right user and/or user session. This correlation is to be done using the requestId attribute value of the QueryResponse.  In case this value is not linked to any current user and/or user session, the event is logged for investigation. 




  • No labels