Child pages
  • UMA telecon 2021-01-28
Skip to end of metadata
Go to start of metadata

UMA telecon 2021-01-28

Date and Time

Agenda

  • Approve minutes of UMA telecon 2021-01-21
  • UMA and FAPI discussion
  • Pensions Dashboard update
  • Other profiles next steps
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Deferred

UMA and FAPI discussion

What is FAPI: https://openid.net/wg/fapi/

Oauth/OIDC security profiles started for Open Banking purposes. UK open banking has accepted FAPI as their security profile. Many UK industries are moving towards FAPI as the baseline security profile.

How do the FAPI profile interact with our own profiling work, both UMA as a profile of OAuth, and downstream profiles such as the Pensions Dashboard? Are there was to converge FAPI and UMA such that they can easily be used together? They are not 'competing' profiles, FAPI is around security and UMA is around delegation + sharing. 

As the pensions dashboard profile is part of the 'financial' industry, there is a likely requirements to realize the FAPI profiles, specifically for strong customer authentication (SCA). 

GNAP ("OAuth 3") is a 'backwards incompatible' iteration of OAuth, incorporating many other protocol goals, including UMA. Suggest we park this and focus on OAuth 2 profiles/efforts.


FAPI is similar to the HEART initiative for Health Care. HEART was security profile of OAuth2+UMA2, including the definitions of FHIR and associated scopes. There is some prior work of using HEART with additional FAPI requirements to secure an UMA implementation. This is the Nordic health UMA profile(https://julkaisut.valtioneuvosto.fi/bitstream/handle/10024/78439/MyData-nordic-model.pdf). Suggest FAPI should take up an UMA 2 security profile in addition to the OAuth2/OIDC profiles. 

There is a push to open data control to end-users "Life-tech" (at least in the UK). FAPI is not enough to realize this(?). FAPI is setup with trust list/directories that in theory create open/wide ecosystems of dynamic client registration between RPs and AS/RS providers. In practice, there are a lot of operational challenges to a dynamic ecosystem. UMA has considered these wide ecosystem questions from both the protocol but also the whole "BLT". 

As a heads up to implementors/vendors. In the UK, the Pension Dashboard software provided to Pension Providers(RS) will need to realize all of the pensions dashboard profile, the FAPI security profiles and the Open Banking data APIs. 

If we believe that FAPI should support a UMA2 security + privacy profile, should we produce and contribute this? Yes. Alternatively, should UMA 2 adopt(recommend?) FAPI as the security profile, and keep all the good privacy work in UMA? Is there any barrier today to using FAPI and UMA? Likely not, but this would require some analysis. 

Let's work towards completing this analysis. Bringing the disparate profiles together removes a lot of uncertain around how different efforts work together. Presumably the financial-grade security is useful in many industries. WG members are encouraged to review FAPI and send any comments/notes to the mailing list.

How does the FAPI work benefit other industry (health care) use-cases? Should be immediately useful as a strong security profile? Health care in the US is working towards very UMA aligned features/requirements. How can our WG better represent UMA in those forums? 


Pensions Dashboard update

Still working through IPR concerns. Ideally want to reference a completely open + free specification. They support the Kantara + WG process, more questions of timing around the profiles availability.

Other profiles next steps

Deferred


Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Karim, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve)

Voting:

  1. Peter
  2. Michael
  3. Eve
  4. Alec
  5. Sal

Non-voting participants:

  1. Nancy
  2. Tim
  3. Colin

Regrets:

  • Andi


  • No labels