Multiple authorisation apps per social agent

We are setting up a WebID provisioning service (called use.id) and one of our customers has a very interesting use case which would accelerate the adoption of Solid: they provide process support so the user has a seamless user journey when s/he connects data from one party to another. For example, when you would start a new business, you need to ask data from your bank (e.g. your account info) and provide it to the company registration office. Their app (let's call it the process supporting app) would support this journey process from start to finish.

This process supporting app is very interesting because it will mostly handle cases in which the user is new to the other actor (e.g. the bank or the notary) meaning that the user would need to go through the authz app time and time again.

However, if the authz app is separate from this process supporting app, the user journey would be suboptimal, which would (indirectly) hinder the adoption of Solid.

Currently, we are thinking about granting this process supporting app the status of an authz app (with explicit consent of the user of course). However, then the user has an authz app which is not lean anymore (it is also used to support processes). As such, we are thinking to introduce the process supporting app as an authz app which can function next to the default use.id authz app.

Yet, this would require a social agent to be able to have multiple authz apps and perhaps be able to indicate a ‘preferred’ authz app.

What does the panel think of allowing more than one authz app per user and allowing the user to indicate a preferred authz app?

No files, tests, or entry points are identified. Start by reviewing the proposal for multiple authorization apps and a preferred app, then determine whether the panel reaches a specification decision; done would be an agreed direction.