New feature of the Salt Edge Authenticator will be the "Consent Management" - a useful tool for user to control the provided to Third Party consents.
Identity Service examples should be updated to show the example of how to store/share the consent with the Salt Edge Authenticator app or with app's SDK.
The consent management is a tool to control consents that user has provided to a certain third party. Hence, our main entity is "consent". According to the API documentation, it is required to poll the consents from server when user goes to Connections page to get them, or to update them.
[x] Application should be able to understand if the connected provider supports the consents. For this, there is new parameter in configuration file of the connection - consent_management. If the value is true - once user gets to the Connections page - the application should request the server fresh consents - to either show the consents that were not there, or to update the current amount of consents. It is not necessary to store the consents in the application for long time (only temporary). If the value is false - then there is no need for certain providers to request the consents. Additionally, if the provider did not update the configuration file and this parameter is missing, the app should perceive this as true and to request the consents. In this case if app receives the error message - will mean that consents are missing. Automatic refresh on cation when user accesses "Connections" page is the only way to update the consents for the connection.
[x] Change "Connected on Mmm DD, YYYY at HH:MM" format to "Linked on DD Mmm YYYY"
[x] If the request to get consents is successful - in the connection card should appear the amount of present for this particular connection consents in format "X consents" (for single - "1 consent"). If consents amount was already present, only the number of available consents should be updated. Please use the "dot" as a divider between consents and when the connection was linked.
[x] If consents are present, the menu should get additional option "View consents". If consents are not present - menu for the connection is kept the same.
2. Consents - "Active consents" page (screenshot 4)
As the consents belong to the single provider, on the page is visible the general info about this provider and consent cards, which represent the each application (third party) to which user has provided certain access.
[x] Page header "Active consents"
[x] Info about the provider contains logo, Provider name and amount of given consents.
[x] The consent card is quite similar to connection card, and has 3 fields: 1) TPP (application) name = tpp_name (please make sure for first letter to always be upper-case, even if it did not come with first upper-case letter), 2) Type of consent currently can be only "Access to account information" (if type = aisp, then use this naming, others will be added on a later stage, and they are: pisp_future with description "Future payment" or pisp_recurring with description "Recurring payment"), and 3) "Expires in X days" (if only 1 - then make it "Expires in 1 day") parameter, which is calculated from the today's date and expires_at parameter. If the consent expires in 10 or less days, the number and word "days" should be in red color and semibold style. On the right there is an "arrow-right" icon, meaning that user can click on the card to get a detailed consent view.
[x] Once user is on the "Active consents" page - please add the option to refresh the consents by "pull down" action.
[x] "Back" button will get user to the "Connections" page.
3. Consent details page (screenshots 5,6,7,8)
Currently, there are specifications available only for the "Access to account information" type of consent.
[x] Page header = tpp_name (please make sure for first letter to always be upper-case, even if it did not come with first upper-case letter)
[x] Below the header, there should be information of how many days are left for this consent. Format "X days left" / "1 day left". Simply the info - no need to add specific styles if the days count is low.
[ ] Content title is "Consent for account information access"
[x] Description is "Consent granted to {tpp_name} application on the following accounts from {provider_name}:".
[x] The window for accounts contains the info on those accounts. Accounts are separated with dividers. App should structure the information as in the design, depending on how many accounts are available in the array. It can be either: a) list of account names (name is the only required parameter), b) list of name + account_number + sort_code, or c) list of name + iban. There are no other options for now. The accounts window is sized depending on the amount of accounts to which consent was provided. Check screenshots 5,7,8.
[x] Below accounts info there might be optionally information about the data type that is shared with third party. It displays if there is some info on array of shared_data, with options balance and transactions that are available in the "Shared data" card as labels.
[x] Below all the info on accounts - there are 2 fields with date when the consent was granted:
Field with value from created_at with structure: "Granted: Month DD, YYYY"
Field with value from expires_at with structure: "Expires: Month DD, YYYY"
[x] On the right from the header (TPP name), there is a button "Revoke". To revoke the consent user has to pass the confirmation step, with title "Revoke consent", description "{tpp_name} service that is provided to you may be interrupted. Are you sure you want to revoke consent?" and options "Cancel" and "Confirm". Check screenshot 6.
[x] "Back" button will get user to the "Active consents" page.
4. Revocation notification:
[x] After what user has confirmed via confirmation step to revoke access to certain TPP, please add the informative message (snack bar message) "Consent revoked for {tpp_name}".
Summary:
New feature of the Salt Edge Authenticator will be the "Consent Management" - a useful tool for user to control the provided to Third Party consents.
Identity Service examples should be updated to show the example of how to store/share the consent with the Salt Edge Authenticator app or with app's SDK.
Reference issue: https://github.com/saltedge/sca-identity-service-example/issues/43
Specifications:
The consent management is a tool to control consents that user has provided to a certain third party. Hence, our main entity is "consent". According to the API documentation, it is required to poll the consents from server when user goes to Connections page to get them, or to update them.
1. Connections page - Consents visibility (screenshots 1, 2, 3)
consent_management
. If the value istrue
- once user gets to the Connections page - the application should request the server fresh consents - to either show the consents that were not there, or to update the current amount of consents. It is not necessary to store the consents in the application for long time (only temporary). If the value isfalse
- then there is no need for certain providers to request the consents. Additionally, if the provider did not update the configuration file and this parameter is missing, the app should perceive this astrue
and to request the consents. In this case if app receives the error message - will mean that consents are missing. Automatic refresh on cation when user accesses "Connections" page is the only way to update the consents for the connection.2. Consents - "Active consents" page (screenshot 4) As the consents belong to the single provider, on the page is visible the general info about this provider and consent cards, which represent the each application (third party) to which user has provided certain access.
tpp_name
(please make sure for first letter to always be upper-case, even if it did not come with first upper-case letter), 2) Type of consent currently can be only "Access to account information" (iftype
=aisp
, then use this naming, others will be added on a later stage, and they are:pisp_future
with description "Future payment" orpisp_recurring
with description "Recurring payment"), and 3) "Expires in X days" (if only 1 - then make it "Expires in 1 day") parameter, which is calculated from the today's date andexpires_at
parameter. If the consent expires in 10 or less days, the number and word "days" should be in red color and semibold style. On the right there is an "arrow-right" icon, meaning that user can click on the card to get a detailed consent view.3. Consent details page (screenshots 5,6,7,8) Currently, there are specifications available only for the "Access to account information" type of consent.
tpp_name
(please make sure for first letter to always be upper-case, even if it did not come with first upper-case letter)name
is the only required parameter), b) list ofname
+account_number
+sort_code
, or c) list ofname
+iban
. There are no other options for now. The accounts window is sized depending on the amount of accounts to which consent was provided. Check screenshots 5,7,8.shared_data
, with optionsbalance
andtransactions
that are available in the "Shared data" card as labels.created_at
with structure: "Granted: Month DD, YYYY"expires_at
with structure: "Expires: Month DD, YYYY"4. Revocation notification:
{tpp_name}
".Tasks:
Screenshots:
![image](https://user-images.githubusercontent.com/38658558/85583897-55677c00-b647-11ea-9a53-5ae43a350949.png) ![image](https://user-images.githubusercontent.com/38658558/85583951-62846b00-b647-11ea-966c-d9d8a20471e4.png)Thanks!