didcomm demo: issuer.example.com: user consent while connecting wallet

[llorllale]

During the process of connecting the issuer adapter with the user's wallet, the user is asked for their consent:

Click to expand


This screen should either be hidden altogether from the user or refactored to make it look like the user is approving Terms+Conditions. Or some other creative solution.

The problem with this screen right now are:

1. The user is introduced to an unknown (by them) "third party application" named "auth-code-client" that wishes to "access resources on their behalf". The user does not know this 3rd party application's identity
2. The user is already interacting with the party that holds the user's data (the issuer - issuer.example.com). They shouldn't have to delegate authority unto anyone else to fetch the data
3. The user might get the impression that they are already sharing the data when in fact that steps comes later

[llorllale]

During yesterday's call there seemed to be confusion and/or disagreement around whether this is a problem or not.

First, we need to be clear and aligned on the model we are demonstrating here.

When we say "an issuer issues a credential to the user" in this demo, we are:

• referring to an interaction between two parties: the user and the issuer
• implying the issuer is the producer of the data

Since in this model there are no third parties involved, there is no one else for the user to delegate authority unto.

After the user has logged in, the issuer offers the capability to "download their credential" via an onscreen button. The user clicks on that button and the issuer fetches the data and transfers it over to the user's agent.

This is akin to downloading a digital copy of your credit card statement from your bank. After you log in, you just click the download button and viola.

[sandrask]

@llorllale Currently the issuer (CMS) contains multiple sets of data for the user and the user is giving consent to the issuer to release (create credential for) certain set of data (represented by scope). This was original requirement from @troyronda. We may not need it any more, however @troyronda has to confirm it.

[llorllale]

@sandrask

Currently the issuer (CMS) contains multiple sets of data for the user and the user is giving consent to the issuer to release (create credential for) certain set of data

I see three parties mentioned here: the user, an issuer of a credential, and a third party collecting and producing the user's data.

Introducing the third party just seems like a demonstration of the OAuth2 auth code flow... which is not very useful in this leg of the demo's flow.