FAPI2 Trust Framework structure
Issue #432
open
As we are moving our efforts to FAPI 2, we had quite a few discussions in FAPI WG about:
- The purpose of FAPI
- Common needs of Open Banking ecosystems
- How some authorization requirements fit in with FAPI security profile
- Where does RAR, CIBA and Grant Management fit in and if Security profile should mandate RAR or Grant Management.
We proposed to introduce FAPI 2 Trust Framework (a family of FAPI2 specifications) described below:
We are asking for FAPI WG members, implementers, vendors, regulators and friends to provide feedback on this proposal.
Comments (26)
-
-
Looks very familiar, obviously has my support
. A lot of these standards have been used in the wild in at least three major jurisdictions. Most are not controversial but I personally would have reservations about allowing any ecosystem to be “FAPI 2.0 certified” without a threat model being created and analysed if they’re cherry picking bits of the base fapi 2 specs to adopt so I don’t think we would want to see fapi for ecosystems certified if the security and authorisation components aren’t used collectively. -
I support any initiative that provides “a standard interoperable approach to the problems we've seen in many ecosystems that have implemented FAPI“.
It is important that FAPI 2 implementations are consistent and interoperable across industry sectors both within and between countries.
-
This is an interesting topic as the FAPI framework can apply to different use case (as highlighted by Steiner). In my view, we should consider the various type of use cases (Health Care, Government, Mobile) where the Financial-grade API applies when developing this framework.
-
Raidiam’s and the Australian Banking Associations position on the subject.
-
I support the idea of establishing a set of profiles as the FAPI2 “family” of profiles. I think the initial split is a good one although open to alternative splits, not so sure I like the “marketing” names either but the general direction of where this is headed has my full support.
-
You put a lot of work into that ABA report Ralph. Your references to Scott Farrell’s reports are helpful.
-
With the growing number of documents in the FAPI 2 family, I think that a split like the one proposed by Dima has to come sooner or later. I would propose a slightly different slicing (or visualization?) though:
- Make clear that FAPI 2 compliant ecosystems need to be based on the Baseline or Advanced Security Profile
- I’m hesitant to put CIBA and RAR/GM into the same “package” - I suppose that the use cases do not necessarily overlap
-
An accompanying “Implementation Rules” (or “Implementation Advice”?) document would capture the basic rules that apply to all FAPI 2 compatible ecosystems, such as:
-
When to use a specific mechanism:
- To avoid the use of home-grown alternatives where FAPI 2 mechanisms are available (like RAR)
- To select the correct security level and security mechanisms
-
How to combine mechanisms
- Testing and certification guidelines
-
So more like this:
-
Not including CIBA with the base line profiles gets my support as a formal profile.
-
I like Daniel’s suggestion.
-
Looks good Dima/Daniel. My 2 cents:
- Agree that CIBA should be its own building block.
- SET is missing from your diagram Daniel. Where would you consider placing that? Would it be another vertical building block on top of the base profiles e.g. Shared Signal Events and Notification Services or the like, or part of one of the building blocks already listed?
- Adjacent guidance includes Implementation Advice and the Attacker Model. I’d suggest putting Certification Testing in as well. I know you make reference to them in your points Daniel, but having this explicit would be beneficial for readers.
- For “Ecosystem Management” would it make sense separating client registration between RP / OP perspective from the interfaces and design of the trust authority (role of an accreditation register). Perhaps this is better labelled as Client Management or the like?
- Having a profile of standards for standardising trust authorities and potentially international interoperability across trust authorities (if client X is a trusted confidential client in AU and there is an arrangement between the UK and AU for accreditation and liability etc, then client X can also participate in the UK). At the very least the standardisation of the trust authority in each local jurisdiction would be valuable. How RPs and OPs establish a trust line with each other and basic discovery data along with the functions of the trust authority vs trust the RP/OP establish between each other.
- I’d suggest keeping Dima’s jurisdictional overlay because it aids comprehension.
To Steinar’s and Bjorn’s comments, at what point does FAPI stop being “financial-grade” and simply a secure API framework? Hopefully I am not being controversial, but should the “F” in FAPI be something else for FAPI 2.0? Similar in thinking to the change from the Read and Read/Write profiles to be Baseline and Advanced profiles.
-
@Mark Verstege This was part of the reason for my comment. I know that this topic has been discussion in HEART and iGov WGs previously. The fact that you’re bringing up SSE just adds to the cross-WG functionality and use cases that was the reason for my initial comment.
-
Mark, you make a timely point about the F in FAPI.
Australia hopes to quickly expand its open CDR ecosystem beyond the finance sector into the energy and telecommunications sectors of our national economy. Other sectors are likely to follow.
As Steinar and Bjorn suggest, an extensible, flexible portable and internationally interoperable FAPI 2.0 has growing appeal beyond the finance sector.
I’ve heard it said that a rose by any name would smell as sweet.
-
reporter
I’ve tried to incorporate Daniel’s approach to base and toppings and keep ecosystem view at the same time. How does this look?
In regards to certification options, we have discussed 2 types (implementation and product) and 2 levels (individual specification and complete trust framework):- FAPI 2 Implementation certification (content depends on the ecosystem requirements)
-
FAPI 2 Product certification
- FAPI 2 Baseline Security Profile certified product
- FAPI 2 Advanced Authorisation Profile certified product
- FAPI 2 Trust Framework certified product - the product that support all FAPI 2 options / toppings
I personally think that “F” in Financial grade is Ok. We can raise this as a separate ticket if there is appetite to discuss it. May be FAPI WG home page should refer to different types of use cases supported.
There are some good suggestions in this thread that can go into the next level of detail or in a separate ticket.
Thoughts?
-
Thanks for the proposal.
I wouldn’t put CIBA, RAR and GM in the same box (see Daniel’s argument).
“System Registration, Discovery, and Management” is a big challenge. We haven’t even come to a conclusion around registration once (Dima and Stuart kicked that off “long” time ago). Adding discovery would make that even harder. I think it makes sense to work on it but I propose to declare it out of scope for FAPI 2.
-
I agree with Torsten. I’m not sure if we need to define the details of the Registration/Discovery/Management part right now. I would imagine that the FAPI 2 Family could be extended later on.
Not sure if ‘FAPI 2 Trust Framework’ is a good name, especially since we use Trust Framework for something quite different in the OIDC4IA specification. Maybe just ‘FAPI 2 Family of Standards’?
I’m fine with Financial-grade.
-
reporter
Thanks @Torsten Lodderstedt and @Daniel Fett
The story that we are trying to tell is that to set up a typical open banking ecosystem you need the following building blocks.
This picture shows how FAPI 2 can help to help with this (overlaying building blocks with FAPI 2 specifications):
In terms of FAPI 2 Family of specifications it would look like this:
This follows closely Daniel’s pizza model (base + toppings).I don’t think CIBA, RAR and GM are in the same box - it was just an overlay (it is related to how you capture and manage authorisation / consent). Certainly, they are not in the same specification document.
Registration/Discovery/Management is a future piece of work. I am happy to gray it out until we pick it up. The reason why I think it should be done eventually, is that UK, Australia, Brasil had to invent (and/or copy) a solution for this common problem. We would want to help new ecosystems by providing an optional building block or two to cover this. In terms of what is included ,we can work through later. This is really a placeholder or a roadmap item at the moment.
What do you think?
-
[edit - I hadn’t seen Dima’s most recent post when I wrote this] Generally the direction seems okay, if rather ambitious. It’s difficult but, as others have pointed out, some things are grouped together that seem not to fit naturally with each other. And if GM is Grant Management, it’s in there twice in the most recent diagram.
“F” for Financial-grade is a whole other conversation, I think. The change from Financial to Financial-grade was intended to make it more generally applicable while keeping any “branding” and name recognition of FAPI. If we need/want to revisit that, it should probably be done on its own outside this already complicated discussion.
I’d push back on the term “trust framework”, which I think is a term that is overloaded to the point of being almost meaningless (or even conveying the wrong meaning). It’s not as catchy but Danial’s digarm just has “FAPI 2 Technical Standards”
-
reporter
Thanks @Brian Campbell
And if GM is Grant Management, it’s in there twice in the most recent diagram.
GM (Grant Management) is a separate specification document, and Advanced Authorization profile ties the specs together. Happy to remove the double reference if it is confusing.
-
reporter
We’ve discussed this on Atlantic and Pacific calls this week. Everyone is comfortable with the high-level approach.
Advanced Authorization Profile specification has been created. We will draft it and come back to the group for formal adoption.
This diagram shows what specifications are part of the framework and shows potential future specifications (details are to be decided when the time comes):
In terms of the naming, recognising that trust framework usually has technical, legal and business area here are some suggestions to narrow the scope down:- FAPI 2 Framework
- FAPI 2 Suite
- FAPI 2 Technical Trust Framework
* we can drop “2” potentially.
Please suggest other options if you feel strong about it, and vote. Hopefully, we can make this decision next week and discuss the next steps.
-
reporter
Last week we made a decision to call it “FAPI 2 Framework“:
And overlay over ecosystem requirements:
I will close this issue now. -
Perhaps examples of how the FAPI 2 Framwork could fit in a data sharing ecosystem could be included?
I really like the EIF model, which separates the ability to interoperate into four dimensions (Legal, organizational, semantical and technical). Maybe something like this would be generic enough:
- The legal dimension (rules/laws/who is responsible?)
- The organizational dimension (code of conduct, agreements, responsibilities etc)
-
The technical standards
- security mechanisms,
- hardening of the protocols etc
- The domain specific stuff
- API specifications
There are a lot of links between the technical and the organizational and legal dimensions, I think it might be important to explain why certain parts of the FAPI framework is useful to fulfil underlying requirements - when would you e.g. use the non-rep part of the framework, and why..
Then again… This might not be the right place for this
-
- changed component to Others
-
reporter
Updated FAPI 2 framework structure based on recent discussions.
-
-
assigned issue to
Dave Tonge
We will attempt to explain this on the website
-
assigned issue to
-
- changed status to open
Update it and add to the Introduction of the security profile?
- Log in to comment
Very cool, good idea.
I am part of a team that is building a trust framework for the health sector in Norway. We are basing our requirements on FAPI 2.0, so I am naturally preoccupied with keeping the profile generic enough for us to continue using it.
We are currently using RAR for fine grained authorization, and point to FAPI 2.0 for client requirements.
There are some specs that are less relevant for our health sector use-case, e.g. the CIBA spec, but I think that most of the standards are reusable in other domains and sectors.