1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Rename and adjust FAPI profiles

Issue #271 resolved
Torsten Lodderstedt created an issue

I see a need to better define the objectives of the FAPI profiles. Additionally, the names “Read” and “Read+Write” seem to imply an assessment of the WG for what use cases the profiles shall be used. I would rather leave this decision to the application and instead suggest to convey the (security) strength of the profile.

@Nat Sakimura came up with the idea to designate them as “substantial” and “high”. This sounds good to me, we also must give the profiles a clear “profile”.

  • “substantial”: - I suggest to make FAPI Read the baseline profile for applications that want to prevent replay and client impersonation.
  • “high”: FAPI RW could be the profile for applications requiring non-repudiation and authenticated messages.

Some ideas what that would mean in terms of mechanisms & features:

FAPI “substantial”

  • Add sender constrained tokens
  • Add PAR and RAR, which is more functional (conveying rich authorization data) than security although PAR also has better security properties than traditional authorization requests

FAPI “high”

  • Signed authorization requests and responses. I personally would prefer to make OAuth-based mechanisms, namely JARM, the default and keep response type "code token" for applications that anyway use OpenID Connect (for ID providing) and backward compatibility to simplify FAPI “high”.
  • PAR MUST be used with signed request objects
  • RS message signing (!)
  • Adding signed token introspection responses seems reasonable to support non-repudiation for the AS to RS communication (if needed)

I think this adjustments will make FAPI even more attractive for a broader audience including new communities outside of the financial space.

Comments (32)

  2. Torsten Lodderstedt reporter

    Discussed this proposal in the call on 9th of Oct. The proposal was supported by the attendees and the following way forward was proposed:

    • current FAPI profiles are renamed as suggested and released as FAPI v1
    • start working towards FAPI v2, which (depending on the WG consensus) will implement the proposal.
    • Nat will post the conclusions to the list to gather feedback of the whole working group.

    ‌

  3. Dima Postnikov

    What about one of these?

    • Basic / Foundational / Light / Starter

    • Advanced / Full / Enhanced / Complete

    ‌

    If it’s too hard, may be Level 1 and 2 or Grade 1 and 2…

  4. Joseph Heenan

    Yeah, I’m kind of tempted by grade 1 / grade 2. It’s really hard.

    The general overall idea of the rename/etc I’m good with, as I mentioned on the call a week or two ago.

  5. Stuart Low

    Agree, the general idea of renaming is a good one, just a challenge to decide what to head towards. It seems there is multiple dimensions to describing the requirements including complexity of implementation (how many things to add), assurance of data integrity (is this data tampered?), front channel vector exposure (MTLS, signing/encryption requirements), back channel vector exposure (should this data be exposed, eg. PII). There’s probably more.

    For my 2c, I think either:

    1. Try and align with similar OIDC structures by tweaking ‘Minimal’, ‘Dynamic’, ‘Complete’ from OIDC. Maybe ‘Minimal’, ‘High Assurance', ‘Complete’?

    2. Come up with a matrix method cross sectioned on ‘Baseline’ (B), ‘High’ (HA), ‘Complete’ (C) and use initialisation, something like the below although really only put out there as a starting point:

      1. Encryption (E) focused/provisions (encryption requirements, mtls constraints etc)
      2. Assurance (A) focused/provisions (tamper protection, signing etc)
      3. Classification (or 'Type’) (C) focused/provisions (type of data, basic data, personalised data (basic pii), indepth personal data (extended pii - like health records)

      Then come up with combinations, initially two to cover the existing parts. So roughly, FAPI-R would be Baseline Encryption, High Assurance, High Classification, BE-HA-HC and FAPI-RW would be High Encryption, Complete Assurance, High (or maybe Complete) classification or HE-CA-HC

    Finally, while FAPI is the “known” term now, we could just rename “Financial-grade” to “Fantastic” and be done with it. 😉

    ‌

    ‌

  6. Dave Tonge

    On the call last week we discussed this issue.

    There is a strong agreement with changing the names.

    However there is not an agreement about the use of “substantial” and “high” - mainly because it is difficult to know which is “higher”.

    From my perspective I’m quite interested in Stuart’s suggestion of a matrix - this would be helpful for the FAPI site at OpenID.

  8. Torsten Lodderstedt reporter

    From a marketing perspective, I would prefer “advanced” and “high”.

    I would propose to leave terms like “baseline”, “low” or potential level numbers 0 and 1 to “standard” OAuth.

  9. Stuart Low

    While there’s work happening on backing with real vectors #163 from a “marketing” perspective perhaps consideration should be given for having presentation format like OIDC’s Protocol Suite breakdown?

    That would base as FAPI Minimal, Dynamic and Complete with components being grouped “feature sets”.

  12. Nat Sakimura

    Hi Daniel, I am creating the agenda for today’s call and I cannot find the “first cut” document that was to be provided by last Wednesday. Could you put a link here?

    ‌

    Also, as to the cheat sheet is concerned, the assumtption A5 “This attacker can read messages sent to and from the token endpoint of an honest AS.” need to be modified somewhat. The point is that cleint can be tricked into believing the attacker controlled endpoint is an honest AS Token endpoint. For example, if the Honest AS was hosted in example.com and the honest Token Endpoint was https://as.example.com/token/v.1/ or something. Thne, suppose there was antoher host in the domain, labs.example.com which was under much lax security policy and the attacker compromsied it to establish https://labs.example.com/token/v.1/ . Then, the attacker tricks the client developer to believe into that this attacker controlled endpoint now is the legitimate endpoint. This is one of the way the code phihisng attack would work. So, to capture this, you probably need to restate A5 as

    A5 “This attacker can read message sent to and from the token endpoint that the client thinks as of an honest AS.”

  14. Torsten Lodderstedt reporter

    Based on what I learned at FData Summit, I would suggest we include PAR & RAR as interoperable way to convey authorization request data from client to AS. Right now, every open banking initiative solves that challenge differently (lodging intent, parameters, …), which is an interop issue. Extending the FAPI Profile scope to include PAR & RAR will make FAPI a complete solution for API authorization.

  15. Joseph Heenan

    I think there’s a choice as to exactly how we do it.

    Certainly including PAR as recommended(“should”) prior to taking the specs to final seems like a no brainer to me.

    RAR seems not quite as complete so potential seems to warrant a little more caution, but then equally I’m not sure I see a lot of harm in doing the same with it and including it as a recommendation before going to final.

    ‌

  16. Torsten Lodderstedt reporter

    The point I want to make is: there is no definition of how to carry authorization data for Financial Grade APIs in FAPI. I think we need to close this gap, otherwise there will be no interoperability on the level of the authorization protocol. Let’s for example assume, NextGenPSD2 and PolishAPI would adopt FAPI today. Letting aside the differences in the differences in the AIS and PIS APIs, this would not lead to bit-wise on the wire interop with UK OB, just because UK OB uses a claims parameter + lodging intent to carry authz data, NextGenPSD2 uses a dynamic scope values + lodging intent, and the PolishAPI uses a JSON based auth request parameter.

    If we want to make FAPI a secure and interoperable authorization protocol, I see the following options:

    • we adopt the UK OB approach
    • we adopt the BG approach
    • we adopt the PolishAPI approach
    • we adopt the approach which was mostly developed in FAPI based on our open banking experience -> PAR & RAR

    If we go for PAR/RAR, I would assume adoption and progress of RAR will be accelerated in the OAuth WG as well.

    ‌

  17. Joseph Heenan

    Understood & agreed.

    I’m not sure how much we want to get into the details on this particular ticket, but it is probably worth saying that (based on my current understanding) PAR & RAR as they stand are not a complete replacement for UK OB intent lodging.

    In particular, the handle returned for an OBUK lodged intent lasts for a long time (potentially years or longer) and can be used by the relying party as a “handle” for a particular rich authorization, to either renew that authorization (due to the PSD2 requirement to do SCA every 90 days for ongoing API access) or for the RP to revoke the access (if the RP no longer wants/needs/should have access to that data).

    Australia are wrestling with a similar problem (but 120 days I believe instead of 90 days).

    It would be good for a clear recommendation on how to deal with these scenarios too I think.

  19. Torsten Lodderstedt reporter

    @Joseph Heenan can you please describe what the objective of the handle is? What I got are two use cases:

    • renew authorization: what does renewal of an authorization mean? What is the difference to the initial authorization?
    • revoke access: access can be revoked using any token issued to the TPP (https://tools.ietf.org/html/rfc7009). My advice would be to issue refresh tokens and (also) use them for revocation.

    ‌

  20. Joseph Heenan

    @Torsten Lodderstedt the API documentation is round about here: https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/master/profiles/account-and-transaction-api-profile.md#account-access-consent-status

    ‌

    renew authorization: what does renewal of an authorization mean? What is the difference to the initial authorization?

    PSD only allows a 90 day authorization for API access to be given. If a TPP wants to continue access after the 90 days (and a few other cases) they need to get the user to go through a strong customer authentication again. This process extends the expiry time of an existing consent without requiring the user to (say) reselect which accounts they want to share or re-check exactly what data is being shared.

    ‌

    revoke access: access can be revoked using any token issued to the TPP (https://tools.ietf.org/html/rfc7009). My advice would be to issue refresh tokens and (also) use them for revocation.

    The requirements to be able to re-establish a revoked consent potentially make standard refresh tokens unsuitable. I can’t claim to understand why standard revocation wasn’t sufficient for OBIE, but perhaps Dave, Ralph or Freddi know. It maybe related to requirements for a bank-side interface for the user to manage and potentially revoke on going consents, I don’t know which vendors support enumerating, introspecting & revoking individual refresh tokens at the AS side. Some ASPSPs also allow the user to complete the 90 day SCA entirely on the bank side, allowing the user to extend multiple-consents to multiple relying parties in a single authorisation.

    (I really hate the 90 day SCA requirement. It’s an awful user experience that frustrates users, but it’s required by law. The ethos is essentially to get the users to explicitly acknowledge, at the bank side, that they still want to share data with the TPPs. I would be considerably better if users were optionally able to decide that they just want to give a particular organisation indefinite ongoing access, putting the control back in the user’s hands.)

    ‌

  21. Joseph Heenan

    For the Australian side, the PDF linked from here gives some background: https://github.com/ConsumerDataStandardsAustralia/standards/issues/85 (probably not enough though). They are currently trying to use refresh tokens, but one of their requirements has ended up with them suggesting that an existing refresh token should be passed back to the bank inside the authorisation request object, and passing refresh tokens through the front channel is raising some concerns: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/57

  22. Torsten Lodderstedt reporter

    renew authorization: what does renewal of an authorization mean? What is the difference to the initial authorization?

    PSD only allows a 90 day authorization for API access to be given. If a TPP wants to continue access after the 90 days (and a few other cases) they need to get the user to go through a strong customer authentication again. This process extends the expiry time of an existing consent without requiring the user to (say) reselect which accounts they want to share or re-check exactly what data is being shared.

    I don’t understand why this requires a handle to be passed to the authorization process. The combination TPP (client_id) and User (internal user id with the ASPSP) should suffice to determine any existing consent. Also this allows to incrementally increase or update the consent if required.

    ‌

    revoke access: access can be revoked using any token issued to the TPP (https://tools.ietf.org/html/rfc7009). My advice would be to issue refresh tokens and (also) use them for revocation.

    The requirements to be able to re-establish a revoked consent potentially make standard refresh tokens unsuitable. I can’t claim to understand why standard revocation wasn’t sufficient for OBIE, but perhaps Dave, Ralph or Freddi know. It maybe related to requirements for a bank-side interface for the user to manage and potentially revoke on going consents, I don’t know which vendors support enumerating, introspecting & revoking individual refresh tokens at the AS side. Some ASPSPs also allow the user to complete the 90 day SCA entirely on the bank side, allowing the user to extend multiple-consents to multiple relying parties in a single authorisation.

    (I really hate the 90 day SCA requirement. It’s an awful user experience that frustrates users, but it’s required by law. The ethos is essentially to get the users to explicitly acknowledge, at the bank side, that they still want to share data with the TPPs. I would be considerably better if users were optionally able to decide that they just want to give a particular organisation indefinite ongoing access, putting the control back in the user’s hands.)

    Thanks. The documents from Australia are very helpful. I think R05 is the game changer: “The solution should accommodate the separate revocation of sharing consent for independently established use cases.“ Can someone explain me why this is needed? I can understand that multiple permissions are managed for the same user/TPP tuple, but to revoke those aspects in existing implementations the user will go to the AS and just revoked them in a self care portal. Externalizing this is a 1st class complexity driver for all parties involved as it has significant impact on the protocol (e.g. the TPP needs to identify the consent it wants to update) and the token handling (number, relationsship to consent).

    The assumption underlying decision option 3 seems to be that refresh tokens and consents have a 1:1 relationship. That, in the end, makes the handling of the client/TPP more complex since it needs to separately handle the different use cases/contexts. I would argue that there is no difference between acquiring independent consents (and tokens) with the same client_id and acquiring the same tokens using different client_ids. Thus I would recommend to use different client_ids for different use cases tight to the same TPP/data processor.

    For the Australian side, the PDF linked from here gives some background: https://github.com/ConsumerDataStandardsAustralia/standards/issues/85 (probably not enough though). They are currently trying to use refresh tokens, but one of their requirements has ended up with them suggesting that an existing refresh token should be passed back to the bank inside the authorisation request object, and passing refresh tokens through the front channel is raising some concerns: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/57

    I share those concerns. Initiating the authorization using a backchannel request (CIBA or PAR) would prevent disclosure of the refresh token in the front channel.

  23. Joseph Heenan

    I don’t understand why this requires a handle to be passed to the authorization process. The combination TPP (client_id) and User (internal user id with the ASPSP) should suffice to determine any existing consent. Also this allows to incrementally increase or update the consent if required.

    The OB UK model allows multiple consents to be in place for each client_id/user/as combination. There’s not really the concept to incrementally increase a consent once it’s granted; adding a new account or moving from balance-only access upto full transaction access requires a new consent. A separate consent is required for each & every payment.

    I don’t really understand the requirements that gave rise to this design. I think possibly one of the concerns was to enable the user to revoke specific consents with one client_id whilst leaving others for the same client_id intact.

    I’m not sure I can answer the Australian question; hopefully Stuart or Dima can.

  24. Daniel Fett

    I think possibly one of the concerns was to enable the user to revoke specific consents with one client_id whilst leaving others for the same client_id intact.

    What is the trust model underlying this? If a user wants to revoke access for a client, that client should not be involved in the revocation process at all. As a user, I cannot trust the client to do the revocation properly.

    (And if revocation is done from the AS’s side, there is no need for a separate representation of consents. The AS can just revoke the access for the client.)

  25. Stuart Low

    Thanks. The documents from Australia are very helpful. I think R05 is the game changer: “The solution should accommodate the separate revocation of sharing consent for independently established use cases.“ Can someone explain me why this is needed?

    Essentially the use case here is that a single Recipient (ie. TPP) may have multiple applications (in the ACCC Register referred to as “Software Products”) and data, or at least consents, should not be co-mingled across them. There is an expectations that participants will keep data sets separated between individual value propositions, primarily because the consumer will likely perceive these as two separate “apps” without realising they may be the same underlying organisation.

    While there are various justifications for this, my understanding is that declaring this is a way of achieving parts of the rules framework notably the principle of “Consent should be specific as to use”. I believe the specific paragraph this requirement comes from is this:

    The ACCC proposes to make a rule to the effect that an accredited data recipient may only use data in line with the uses to which the consumer has consented, and that if an accredited data recipient wishes to use data that it has received from a consumer for a use that was not covered in the original consent, it will be required to seek new consent. This will help ensure consent is specific as to purpose.

    About:

    The assumption underlying decision option 3 seems to be that refresh tokens and consents have a 1:1 relationship.

    This is the assumption yes although this appears to be as a follow-on to a previous decision to not use alternative methods such as CIBA primarily driven by complexity to implement. There is another decision related to this available within Customer Authentication Flow DP35.

    With regards to:

    That, in the end, makes the handling of the client/TPP more complex since it needs to separately handle the different use cases/contexts.

    Yes, it absolutely does, in fact consents are Holder Brand, Software Product, Consumer triplets where there can be one or more software products per Recipient (TPP) and one or more holder brands per holder (ASPSP).

    I share those concerns. Initiating the authorization using a backchannel request (CIBA or PAR) would prevent disclosure of the refresh token in the front channel.

    In my opinion, and I will probably never change my mind, presenting a refresh token on the front channel is fundamentally a “bad idea”. The proposed solution appears to be effectively a workaround to avoid reconsidering previous decisions such as, for example, aligning with a CIBA flow. It also doesn’t appear to have been attached to a serious security evaluation of the impacts of doing so, which is what led to my ticket opening that @Joseph Heenan linked.

    I suspect the only way of changing the direction of the CDS is for someone to build an alternate consent flow leveraging existing & emerging standards that systematically meets the ACCC rules framework, validate it, obtain broad WG support, obtain reasonable Holder support and then propose it. Unfortunately this will involve a significant amount of effort to produce so it’s possible the Australian governments political objectives will take precedent.

  26. Torsten Lodderstedt reporter

    Essentially the use case here is that a single Recipient (ie. TPP) may have multiple applications (in the ACCC Register referred to as “Software Products”) and data, or at least consents, should not be co-mingled across them.

    If that’s the objective, why isn’t just every of those applications equipped with a dedicated client_id? That’s a much simpler solution than using refresh tokens as reference to consent objects.

  27. Dave Tonge

    So in the UK there is the possibility of having multiple consents per tpp client_id/bank pair. I was very much in favour of this, however I’m beginning to think that the constraint of only having a “single” consent per tpp client id/bank would be a better system. It would greatly simplify things. As Torsten says, legitimate use-cases for multiple consents per tpp/bank could be handled by multiple client ids.

  28. Stuart Low

    If that’s the objective, why isn’t just every of those applications equipped with a dedicated client_id? That’s a much simpler solution than using refresh tokens as reference to consent objects.

    @Torsten Lodderstedt I may have mistyped my first reply with a reference to “software products”, for products that are completely separated, yes, a separate client_id is issued. The challenge comes about for situations where there are different sets of features in a single product. This may also include those that cross utilise software products. Fundamentally it revolves around the statement of “Consent should be specific as to use”.

    As an overly simplified example, and trying to use a policy lense versus a raw technical one, let’s say I am an “All in One Banking” application FinTech. My app has a few features:

    1. View bank account balances
    2. List transactions
    3. Life insurance provider integration
    4. Private healthcare provider integration

    To deliver (1) and (2) I require the consent of the user for their balances and transaction information. When I request that consent I specify it is for the “Purposes of showing your bank account balances and letting you browse transactions” AND I specify it’s for 3 months. As far as oauth goes this would be granted (over simplified) scopes of list_balances and transaction_list.

    The user then wants to get a life insurance quote, in order to optimise the offering we want to read the users detailed transactions in depth possibly for 3 years history but only have access to these records for a limited period (let’s say it takes a week to approve the quote). Consequently I then request consent with a reason of “For the purposes of providing a personalised life insurance quote from our partner XYZ Inc” for a period of 1 week. In order to deliver this I need list_balances, transaction_list and detailed_transaction_list. As far as the rules definition I am not allowed (or at least not meant to) leverage the consent previously give for list_balances and transaction_list for the insurance use case. There’s a variety of reasons for this mostly revolving around traceability (i gave consent for you to do a quote and you made the following calls) but also avoiding deidentification across logical boundaries (ie. a bank which also has an insurance arm, from a regulatory perspective, these datasets should [and in most cases are mandated to] be kept separated).

    (4) as specified above is a similar outcome as (3). I added it though to highlight it’s possible you could get two different features with the same underlying scope requirements but they would still need to have separate explicit consents with the consent text being customised (and I believe approved by the regulator) as to what it was for.

    Not sure if I’ve made this thread more confusing, it does feel like it’s gone off-topic. Perhaps we should rename this to “FAPI General Discussion” and open a fresh “Rename FAPI”? 🙂

    ‌

  29. Dima Postnikov

    I agree with @Torsten Lodderstedt that it would be great if FAPI provides options to carry authorisation data. This would certainly make it easier for Australia not to come up with another approach.

    I am not sure if there is one way to carry authorisation data that can fit all use cases and regulations. I think there will be multiple options with the guidelines on their use.

    I also agree with @Joseph Heenan , that there should be a separate ticket focusing on how we can can carry authorisation data between the parties. This ticket should probably just confirm the inclusion of this topic in one or both profiles discussed. Should we move this discussion to a ticket raised by Torsten? This is a massive topic on its own.

    In terms of Australian requirements (my interpretation):

    1. Consent dashboards on both data recipient (aka TPP) and data holder side (ASPSPs). This means, there should be a way to synchronise these (including up-to-date status and consent content, not just renewal and revocation). Long term, not in a current Australian context, I see new use cases where TPPs act as consent aggregators with consent being a resource on its own.

    @Daniel Fett in regards to your earlier comment, Australian regulators are mandating TPPs (and ASPSPs) consent revocation process (including data deletion or de-identification) and treating compliance with is as conditions for the accreditation.

    2. Fine-grain consent is the future requirement coming from all participants and CX working group. They refer to it as permission level (e.g.: “debits only”) as oppose to a data cluster level (e.g.: “all transactions”). There is no solution currently suggested (backlog). It looks like, in a medium term, Australia is moving towards multiple concurrent consents for the same client_id. I see potential use cases where a customer can grant TPP access to multiple accounts with different expiry dates and different permissions but I agree with @Torsten Lodderstedt and @Dave Tonge that this complicates consent solutions.

    I don’t believe we can mandate single consent for all use cases. We could defer the design until we have a real use case to solve for (or we could use @Stuart Low’s “All in One Banking” fintech in a previous as an example - just came through as I am typing).

    Note: In my opinion, issue #85 (@Joseph Heenan mentioned it above) doesn’t describe all available options and appropriate pros and cons.

    3. Renewals / re-authorisations can be initiated in user’s presence on data recipient side (this where some handle like consent_id would be useful). Periodic renewals can also be initiated in a decoupled manner (with user’s presence or without). There is a general agreement that CIBA could be used for this use case but it’s not in the standards yet (backlog).

    4. Joint and business accounts are in future scope too. There is no confirmed solution at the moment but this is where CIBA can be used to capture additional authorisations. Consent API and consent handles can be used to convey the details about authorisation to TPPs.

    PS In my personal opinion, “Refresh token in a front channel” is a workaround that deals with current limitations of the consent solution..

    In terms of what Australia need to achieve the requirements above (my interpretation):

    • Ability to convey authorisation requests.
    • Ability to handle complex / fine-grain consents objects.
    • Ability to support redirect and decoupled authorisation flows for initial authorisation and renewals.
    • Ability to synchronise consent between different parties (pull and push).
    • Possibly, ability to support multiple concurrent consents.

    Hope this makes sense. Let me know if you need more information..

  31. Daniel Fett

    Since we have settled with (and started work on) FAPI 2.0 Baseline and Advanced, I think that we can close this issue.

  33. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
resolved
Component
–
Milestone
–
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!