UX: Request Attribute Flow

[TimSpeelman]

The basic AttributeRequest UX flow:

1. Select a provider
2. Select an attribute offered by that provider
3. (opt.:) Share attributes required for that attribute
4. Accept the offered attributes into wallet

The set of providers is preconfigured into the application. The set of attributes (2) and the requirements (3) may be preconfigured, or loaded dynamically based on the user's choices at (1) and (2) respectively. Fow now, we will preconfigure everthing.

How do we model the AttributeShare and AttributeAccept procedures? We can imagine that AttributeShare may also be used in a different setting, i.e. not initiated by the user. The same holds for AttributeAccept.

• AttributeShare:
  • Receiver : the identity / logo of the party receiving the data
  • Reason : the reason provided for sharing the data
  • Attribute[] : the list of attributes to be shared
• AttributeAccept:
  • Sender : the identity / logo of the party sending the data
  • Attribute[] : the list of attributes to be accepted.

As the AttributeRequest flow contains multiple steps across several views, we need to somehow keep track of this process, either in the front- or backend. Also, when the user quits the procedure, we must lose track of the process. State alternatives:

• URL query string
• Front-end memory
• Back-end memory

Let's first try the front-end memory.