-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modification Request for Stages of Get Metrics v5 "abandonmentsByStage" Object #618
Comments
Any change to Get Metrics endpoint at this stage would likely be a new endpoint version. Implementers activating November 1 have the option, and are likely, to implement Get Metrics V5 so there will be live installations in play prior to the most optimistic timeline of resolving this request. Unfortunately @NationalAustraliaBank I think you're stumbling on what I said in DP322:
But no-one in government listened so gg. |
The Get Metrics V5 abandonment by stages guidance has been updated to provide additional clarity. The update aims to clarify expectations of the In relation to your second concern, as stated on the MI17 call when this issue was discussed, the stages are intended to report on key stages of abandonment in the authorisation flow, and Please post a comment if you have further queries, or if you think this issue can be closed. Thanks |
Please add a comment if there are further concerns, or this issue will be closed on 31 May 2024. |
Background: In Get Metrics v5, below 5 abandonmentsByStage are introduced for detailed level metrics.
preIdentification - The number of authorisations that commenced with the data holder but the customer did not successfully identify their profile or user ID
preAuthentication - The number of authorisations where the customer identified themselves (ie. they successfully identify the customer profile to use for the authorisation) but failed to provide a valid OTP or equivalent
preAccountSelection - The number of authorisations where the customer successfully authenticated with a valid OTP or equivalent but abandoned the process before selecting accounts
preAuthorisation - The number of authorisations where the customer has passed the account selection step but abandoned the process before approving or rejecting the consent being requested
rejected - The number of authorisations where the customer actively rejected the authorisation rather than abandoning the process
failedTokenExchange - The number of authorisations that completed the interactive flow with the consumer authorising the consent, but the ADR failed to - or was unable to - obtain a refresh or access token using the authorisation code.
Issue: The separation of various phases may cause security and overhead solution complexities.
Area Affected:
Get Metrics v5 “AuthorisationMetricsV2 -> abandonmentsByStage” object
Changes Proposed:
Concern 1: In general practise and from security perspective, the “preIdentification” and “preAuthentication” phases should not be separated from each other. For example, user should not know which one amongst the userID or password is incorrect as it defeats the whole purpose of secured authentication.
Proposal 1: Either the “preIdentification” and “preAuthentication” phases should be clubbed into one OR remove the “preIdentification” phase.
Concern 2: Having separate “preAccountSelection” and “preAuthorisation” phases will create overhead solution complexities on Data Holders to monitor traffic on the account selection page. Also, these 2 stages will achieve the same purpose of understanding any abandonments before consent creation.
Proposal 2: The “preAccountSelection” and “preAuthorisation” phases should be clubbed into one.
The text was updated successfully, but these errors were encountered: