Interaction Model Working Group Collaboration Space

Introduction

Function model File:Functional Model Deliverable Version 1 (committee approved).docx has outlined the core functions that are provided by IdEF. The model also identified the roles and actors, functions provided for the sake of administration and operations, and governance and accountability. The model clearly defined these various functions. However, the model does not delve into the scenarios in which these functions will be used. Certain functions will be relevant in a scenario and not so in other scenarios. For example, creating a digital identity (registration) can happen with one entity, and that too only one time. Credentialing also might happen at the same entity, but possibly more than once. An authentication process might involve interactions between different entities/roles (IdP, RP, User, etc.) that require different privacy, security, UX and other considerations.

This document is intended to bridge the gap from the functional model to understanding the different considerations. Such considerations will create a context for deriving requirements – like security requirements, UX requirements, and privacy requirements, so on.

View the presentation for a detailed overview of the motivation and approach to this work. File:InteractionModel v2.pptx

Overview

What

A capture of what an eco-system transaction looks like (realized as a picture),

1. show user interactions with different service providers (actors) in the system (to perform various functions captured in the functional model document), and
2. how service providers and users form the ID eco-system (the glue, in terms of enrolling into eco-system, trust relationships, etc.)

Why

1. Bridge use cases with Functional Model - in terms of functions and roles
   
2. (Create a 'consistent' model across use cases (that is, the use cases can 'fit together' to form the eco-system whole))
   
3. Provide a frame of reference for discussions within (various committees of) IDESG
   
4. Provide a frame of reference for drafting requirements (put requirements in a context)
   
5. Easily explain the eco-system to outsiders (adopters, service providers, users)
   
6. Provide IDESG a way to assess services as trustmarks

How

Functions and roles identified in the FM are the 'scope'
Start with logical sequence of functions (from a user perspective)
For each function from that sequence,

1. identify the use cases already documented,
2. use those use cases to identify the interactions required to fulfill that use case

How to use

The goal of this document is to provide a hierarchical and extensible structure to capture usage scenarios, along with a provision for capturing different considerations at every node in the hierarchy.

File:Figure1.png

Scenarios are not numbered per se, but are referenced by their names - and names are unique only within the current parent scenario.

A scenario at any level in the hierarchy consists of a name, description, and at least one picture – identifying the interactions that take place in that scenario. Each scenario is identified by the following attributes.

1. Scenario name
2. “Corresponds to” (interaction identifiers from the parent/other scenario(s) - provide link here to parent/other scenario)
3. Scenario description
4. Variations [Optional]
   • Scenario picture

Note that ‘corresponds to’ may contain one or more interaction identifiers from one or more other / parent scenarios, that this scenarios drills down into. Such provisioning allows for ‘utility’ scenarios that are like utility functions in programming, they can be referenced/used anywhere else, meaning they ‘come into picture’ in multiple scenarios.

Each scenario may be visualized in multiple ways. For example, a registration of digital identity may be done either through internet or by physically approaching a registration authority. The picture corresponding to each variation depicts the interaction involved in that variation. Note that if, in a particular scenario, there are no variations, then 'variation number' may be omitted, and only the scenario picture included.

There is no one way to draw the scenario picture. It could be of swim-lane variety, process flow type, or any other. However, the important concept is that every interaction has an unique identifier. Each interaction is identified by the following attributes.

1. Unique Identifier
2. Name/phrase
3. Description
4. Any data that can be identified (that flows as part of the interaction)
5. Sub-scenarios that may cover this interaction in more detail (provide page links)
6. Use cases covering this interaction

The unique identifier could be a number, but it is suggested that letters be used instead of numbers, to avoid hinting that the interactions occur in a particular sequence. Also, when letters are used, they do not have to be single letters, any string may be used (Interaction AA, for example, or A1). Also, use of letters allows visualizing cases where the steps occur in different combinations, or a particular step (or sequence of steps) is repeatable (or vice versa, ‘supposed to occur only once’).

Additionally, each interaction has placeholders for capturing the following (these are sections)

1. Privacy considerations
2. Security considerations
3. Standards considerations
4. UX considerations
5. Policy considerations (?? Not sure if this is subsumed by other ones here)
6. Other (social, accessibility, etc.)

Any reference to an interaction is made as ‘interaction ‘X’ in scenario <<link here>>’. Similarly, the particular considerations section is identified as, for example, ‘Security considerations’ under ‘Interaction #10 in Scenario <<link here>>’.

Example

Section	Content
Glossary	Glossary
References	List of references used all through this collaboration space

High-level Scenarios

Primary Use case scenarios