Possible support for "embedded" SCA mode

Issue #295 new
Dave Tonge created an issue

There is currently a legislative requirement for some banks in the EU to allow TPPs to use an “embedded' mode where the TPP collects the user’s credentials and passes them through to the bank.

While this is not our recommended approach, maybe we should consider a way of supporting it. This would help with harmonisation efforts so that we can try and get FAPI adopted more widely.

This is how the Berlin Group support this type of interaction:

It is important to note that there is a requirement for the TPP to receive back a challenge to present to a user.

One idea for how to implement this would be to use CIBA as it already has the concept of an “authorization session” via the auth_req_id.

The flow could be:

  • RP → AS: /bc-authorize Create authorization request with a parameter indicating that embedded auth is preferred
  • AS → RP: Ask the user for username/password
  • RP → AS /token {auth_req_id, auth_params: {user, password}}
  • AS → RP: Ask the user for OTP
  • RP → AS /token {auth_req_id, auth_params: {OTP}}
  • AS → RP Token

No new endpoints would be needed. We would need extensions to the backchannel authentication endpoint and the token endpoint.

Comments (12)

  1. Anders Rundgren

    Note that EMV does not require a challenge from the TPP, it is created entirely locally in the payment terminal.

    Yeah, here are 9 billions of EMV cards that currently cannot use Open Banking APIs.

  2. Joseph Heenan

    It’s an interesting idea.

    A few thoughts:

    1. Doing user authentication at the token endpoint seems conceptually to be a notable deviance from current CIBA/OIDC/OAuth, and that may outweigh the advantage of not creating a new endpoint
    2. I wonder if it might be bit more flexible, both for vendors & banks deploying this, (and possibly resolve point 1) if we did something [not unlike some of the concepts in oauth.xyz/TxAuth] where the AS returns a “do this then call this url” type structure. But then that’s almost what your suggestion does but with the url always being the token endpoint. It’s also not dissimilar to the way CIBA expanded the token endpoint to return ‘not yet’ in the polling case.

  3. Joseph Heenan

    Anders: I don’t even understand how you see EMV cards calling APIs.

    For clarity, my comment was a response to Dave’s initial suggestion.

  4. Anders Rundgren

    @Joseph Heenan I imagine that @Dave Tonge 's posting was a direct reaction to my mail which also had you as recipient. The NextGenPSD2 folks want to support EMV cards by bundling EMV-signatures to payment requests. This will make their API compatible with Apple Pay as well as traditional EMV cards.

    That’s (IMO…) way more interesting than targeting outdated solutions like “Sofort” (which probably was the origin for the Embedded SCA mode).

  5. Francis Pouatcha

    The first design decision to be taken here is the definition of a pre-authorization request (we can call prepare service request). the general open banking service flow will look like:

    1. prepare service request : returns the authorization flow
    2. authorize service request : returns the authorization token
    3. confirm service request

    “prepare service request“ in NextGenPSD2 are payment-initiation-request, consent-initiation-request.

    This pre-authorization request shall be independent of the "AuthN/AuthZ Flow/Protocol". The final decision on whether to AuthZe this “service request“ is taken by the ASPSP. Recall that according to European PSD2 RTS, a service request might be exempted from SCA leading to. no authorization at all.

    In existing open banking implementations, the ASPSP is a composition of an AS and a RS in oAuth jargon (or OP and RP in OIDC language). As for now there is no clarity on wether the AS or the RS is the. destination of the service request. This is why we will use the ASPSP bellow to represent the ASPSP-AS and the ASPSP-RS.

    The decision on whether and how to authorize a service request looks like:

    • TPP must collect specifics of the service request (transaction), like the consumption device, transaction details and add them to the service request.

    • TPP shall declare his AuthZ capabilities and preferences [decoupled (CIBA) || redirect || oauth || embedded]

    • If known, TPP must add an indication of the PSU identity to the AuthZ request (situational)

    • Based on this details, based on ASPSP capabilities, based on ASPSP known PSU AuthZ capabilities (SCA App, risk profile)

    ASPSP will select an AuthZ flow and instruct the TPP to proceed accordingly.

    A big design decision to be made is on how to proceed with preauthorization request (or prepare service request). These might also be very cumbersome and their processing might not be possible without interaction with the ASPSP-RS.

    → We can decide to direct this pre-authorization request to the ASPSP-AS, and let the ASPSP-AS collaborate with the ASPSP-RS to take the decision.

    → We can decide to address the pre-authorization request (a.k.a. prepare service request) to the ASPSP-RS and let the ASPSP-RS generate AuthZ requirements (see RAR, JAR, AuthZ-protocol) that will be used to inititate the AuthZ process with the ASPSP-AS.


    • CIBA "Authentication Request" is looking too protocol specific, to be used as a pre-authorization request. In particular the asynchronous design deeply rooted in the protocol.
    • PAR - RAR/JAR also provide some hint on how to approach the embedded design in an oAuth environment. But still too limited as the mapping of the service-request to the RAR, JAR is left to the oAtuh Client (TPP).

    I will take time this weekend and suggest a sequence of call that could be used as an entry point to address the embedded workflow.

  6. Francis Pouatcha

    This a sample sequence diagram showing all three auth flows for open banking (embedded, decoupled and redirect) including the role of ASPSP’s AS, Open Banking API (RS) and TPP. I also separated the RO view into consuming device and auth device.

    Here is the corresponding plantuml code, in case there is any modification to be done.

    participant "PSU\nResource Owner\nConsuming Device" as RO
    participant "PSU\nResource Owner\nAuth Device" as AuthD
    participant "TPP\nClient\nRP" as Client
    participant "ASPSP\nAuthorization Server\nOpenID Provider" as  AuthServer 
    participant "ASPSP\nResource Server\nOpen Banking API" as RS
    RO -> Client ++ : PSU initiates a payment via TPP
    Client -> RS ++ : Payment-Initiation Request
    note right of Client
        - JSON, PAIN.001,  MT940, ... (amount, payee, date)
        - Country specific data
        - AuthN-Constraints (id-token, acr, exp, ...)
    end note
    opt "Payer & Payer Account Known"
    RS -> RS : validate Payment\ncheck availability of fund
    RS -> RS : validate AuthZ\ncheck SCA exemption
    return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
    note right of Client
        AuthZ protocol decision taken by ASPSP-RS   
        - AuthN-Constraints: see above
        - AuthZ-Constraints:
          - PaymentId (a.k.a Transaction reference, TxRef)
          - Exemption if present, no further AuthZ.
          - Auth-Protocol (TxRef XOR Rich Authorization Request:RAR)
    end note
    Client -> AuthServer ++ : AuthZ-request(AuthN-Constraints, AuthZ-Constraints)
    note right of Client
        - Protocol dependent AuthZ-request [CIBA, oAuth-PAR, ...]
        - AuthN constraints (acr, exp, ...)
    end note
    AuthServer  -> RS ++ : load RAR from Payment-Initiation Request (PaymentId)
    return RAR
    return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
    loop "while Challenge" "No initial challenge in case of exemption. Access token present."
        alt "EmbeddedChallenge"
            Client -> RO ++ : AuthN/AuthZ-Challenge 
            AuthServer  --> AuthD : inherent challenge message (dynamic linking, e.g. TAN)
            note right of AuthD
                A challenge inherent to payment might hae been
                sent to PSU auth device.
            end note
            return AuthZ-Grant
            Client ->  AuthServer  ++ : AuthZ-request(AuthZ-Grant)
            AuthServer  -> RS ++ : update Payment-Initiation-Request
            opt "Payer account known"
                RS -> RS : validate Payment
                RS -> RS : validate AuthZ
            return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
            return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
            deactivate Client
        else "DecoupledChallenge"
            AuthServer --> AuthServer ++ : Start back chanel auth
            AuthServer  -> AuthD ++ : push AuthN/AuthZ-Challenge 
            return AuthZ-Grant
            AuthServer  -> RS ++ : update Payment-Initiation-Request
            opt "Payer account known"
                RS -> RS : validate Payment
                RS -> RS : validate AuthZ
            return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
            AuthServer  -> Client : AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
            deactivate  AuthServer 
            note right of Client
            could be psuh, poll, ping
            end note
        else "RedirectChallenge"x
            Client --> RO ++ : Redirect to  AuthServer  
            RO <->  AuthServer  ++ :  AuthN/AuthZ
            AuthServer  -> RS ++ : update Payment-Initiation-Request
            opt "Payer account known"
                RS -> RS : validate Payment
                RS -> RS : validate AuthZ
            return Payment-Initiation Response(AuthN-Constraints, AuthZ-Constraints)
            AuthServer  --> RO :  Redirect to Client (AuthZ-Grant)
            deactivate AuthServer
            RO -> Client ++ : AuthZ-Grant
            Client ->  AuthServer  ++ : AuthZ-request(AuthZ-Grant)
            return AuthZ-response(AccessToken | Challenge(AuthN*, AuthZ*))
            deactivate RO
    note right of Client
        All three protocol flows (Embedded, decoupled, redirect) are completet when the Client/TPP obtain
        an access token and there is no more Auth[N|Z]-Challenge. This access token will be used to confirm
        payment at the resource server.
    end note
    Client -> RS ++ : Payment-Confirmation Request [AccessToken]()
    return Payment-Status
    Client --> RO : Payment-Status

  7. Tom Jones

    i guess you guys should look at the solutions proposed in the US in the last century. Protocols like STT, SET and ANSI X9.59. They all became too complex for user adoption and so failed to be adopted. Sounds like y’all are headed down the same path, so i suspect you will have the same result.

    To Anders point. I would say, if you want an electronic check, then just create an electronic check and use the existing ACH for payment.

  8. Francis Pouatcha

    Display all three authZ flow in a single diagram has the purpose of agreeing on a common terminology, a common language we can use to reduce misunderstanding. Payment/Banking has never been simple due to AML and other actions and reporting provisions from regulators. Trying to use existing protocols like OIDC to map these payment protocols requires a dialog like the one we would like to start here. We need a common language over all schemes/flows like CIBA, oAuth/Redirect, Embedded.

    • Using common term will help narrow differences
    • Having the same semantic behind calls will also simplify task of OPs and RPs in supporting all alternatives.

  9. Anders Rundgren

    @Tom Jones @Francis Pouatcha A core problem is the “value proposition” for regulated payment services since TPPs are (AFAIK…):

    • not permitted creating keys and authenticate users (delegation)
    • unable using the (nowadays sandboxed) keys provided by the banks in their own apps

    TPPs who want to be “creative” are thus stuck with Web applications and dubious authentication methods like SMS callbacks.

  10. Ralph Bragg


    The model proposed here seems to be the same same as the “lodging intent pattern” already used by the OBIE? Lodge a payment request, perhaps using an id_token to identify the requesting party. Bank responds with either. OK Done or No I want authorization please initiate X flow. If one of the options was a that a customer has a means of signing an embedded document then please just resubmit the pain message with a signature from the customer to bind this transaction?

    I must still be missing something so my apologies. Next call can we discuss?

  11. Francis Pouatcha

    Hello Ralph,

    All correct. The intention of the diagram above is to achieve such common understanding. Embedded in the context of the diagram above means the AuthN and AuthZ process in embedded in the user interface provided by the TPP. Means no redirection.

    Many types of embedded AuthZ:

    • Sending a PSU signed payment request (what you mention above)
    • Enter banking password (PIN’s) and TAN’s in the TPP user interface. (Recall EBA’s RTS introduced a mandatory second factor for login to prevent misuse of PSU permanent password/PIN).

    The addition to current FAPI will be the generic Challenge/Response process with the TPP transporting PSU auth credentials to the ASPSP’s AS.

  12. Log in to comment