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

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2021-02-24_Atlantic

View History

FAPI WG Meeting Notes (2021-02-24)

The meeting was called to order at 14:05 UTC.

1.   Roll Call

  • Attending: Nat, Daniel, Torsten, Takahiko, Brian, Dima, Lukaz, Joseph, DOn, Francis, Kosuke, Ralph, Brian Chris,
  • Regrets:
  • Guest:

3.   External Organizations (Nat)

3.1.   W3C Web Payment Interest Group (John)

Nat has been communicating with someone at FIDO and will start attending W3C group meetings soon.

3.6.   UK (Don/Ralph)

  • Talked to Fiona Hamilton on the history of OBIE and OIDF.
  • Planning to do a deeper demo of conformance suite.
  • Bill Roberts and UK Finance is working on how to change the organization of OBIE.
  • Timeline is within next 12 months.
  • Some parts are to be handed over to some other orgs. It is very fluid.
  • UK Finance will be taking over the standards for Financial APIs.
  • Open Energy. Energy ecosystem modeled on UK platform RAdium to be set up by July 2021.

3.7.   USA

OIDF and FDX is completing a legal agreement on use of OIDF trademarks.

Rounding up on existing liaison agreement that lays out “rules of engagement” for adoption of FAPI and self-certification test suite results as part of their certification program. Announcement to be made at their Global Summit in April.

Ralph: Some of FDX’s RFCs and extensions haven’t had much scrutiny from IETF and OIDF. There are duplications of DCRs claims of fields that have already been defined. At what point does OIDF say no to these and not certify them because they are not aligned with OIDF or haven’t been through appropriate governments or we’re concerned that could introduce certain challenges? Where does the line get drawn between consent authorization and security standards?

Don: Development and evolution of FAPI belongs to OIDF. Look to FAPI working group for how the standard and the certification program will evolve. The foundation's role is simply to protect its processes and its trademarks, but also to provide a clear working environment for its working groups. We’re going to continue to help FDX and help organize their early stage certification program.

Lukas: We need to promote FAPI in such a way such that there is an isolation of FAPI and FDX’s extensions. There will be more cooperation between FAPI and FDX and we’re going to have clear isolation in the test certification on what is FAPI and what is FDX. FDX would rather use FAPI.

Torsten: I don’t understand how the cooperation will be structured. We presented Grant Management to them a couple of times. There were lots of questions but no one has come back to discuss a way forward. There was no feedback. How is the cooperation going to be structured? There are occasional meetings with no follow up.

Don: The most effective way to impact development of FAPI is to join the FAPI WG. I keep inviting FDX members to join FAPI. The developer community for FDX is new to OIDC, FAPI. We hope that we can schedule a series of workshops that will provide some education for them. We haven't finalized those workshops yet. FDX members can join OIDF and contribute to standards.

Joseph: FDX WGs are well coordinated with regards to standards between their WGs.

Lukas: There may be some legal obstacles as well. FDX meeting information must be kept within FDX and may not be disseminated to outside groups. So even if there are members in FAPI and FDX, they cannot distribute the information to the FAPI WG.

Nat: What is the current liaison setup with FDX?

Don: Currently, OIDF is working at maximum transparency. FDX members do not have the same flexibility to report discussions. OIDF is looking for practical ways to benefit from more open exchange within legal limitations of their members. We have the opportunity with the FAPI FAQ and roadmap to provide to FDX and all of its members as clear of a view as possible as to the current state of FAPI and its development and future direction. We will share the drafts with FDX members and invite them to comment and provide feedback.

Chris: When developers start building FAPI and FDX together, that will get people to start having conversations and rethinking sooner and will expose things that need change.

4.   Events (Nat)

4.2.   KuppingerCole Event on March 3

4.4.   Identiverse

June 21-23, 2021. Identiverse tickets are available. Joseph will do a presentation on latest practices for OAuth 2.0 and OIDC on mobile.

4.5.   OIDF Workshop

Don will send information to mailing list.

5.   Adoption of the Grant Management Draft (Nat/Dima)

  • Announced the call for adoption on the 17th.
  • No objection till today, so it is now adopted.
  • Thanks the SG for taking this forward.
  • Dima would like the WG homepage updated to include the specification.

6.   PRs (Dave)

Edmund to produce HTML version for review before submission to OIDF secretary.

7.   Issues (Dave)

Lots of new Grant Management issues

Filip raised questioned about the philosophy we will pursue with Grant Management, where we assumed that the grants are fully and explicitly managed by the client. If the client does not specify a grant_id, there's automatically a new grant and grand_id being generated, which means a new concurrent grant setup. Filip proposed that this be an option where the client does not need to pass the grant ID but the AS is not going to be establish a new grant, but just return the grant ID for the grant it picked for that transaction.We should talk in the group what we want to achieve. I would like to know other people's opinion.

Dave: Can we provide a way for a client to request a new grant? If they don't specify a client ID and they don't specify they want a new one, then the AS can at its discretion decide what to do.

Torsten: Right now, there aren't just two options.

  1. Omit the grant ID and a new grant is created
  2. client passes a grant ID in the parameter, then this grant ID is used.

If we want to allow the client to leave the decision of whether a new grant is being spawned to the AS, we need to have a signal from the client to the AS. We originally had an additional parameter called grant management mode that we could have used for that, but was stripped in order to simplify the specification.

Brian: It's extremely difficult to reason about what the different combinations of parameters and metadata fields actually mean, in terms of expected behavior. Simplification actually made it more difficult to understand. I’d like some improved clarity behind the reasoning.

Dave: I see downsides to just automatically creating a new grant.

Takahiko: We don't have any metadata which describes characteristics of refresh token behaviors. I suggested that we define the meta- data. There are 2 ways to control the behavior:

  1. Define client metadata
  2. Define request parameter

Torsten: One of the reasons why we went for the client policy approach is that most features in the OIDC and OAuth just work that way. The client specifies a policy or somehow sets up a policy that controls a lot of the behavior. And only a couple of things are controlled by parameters. iI feels more in line with the design philosophy of the ecosystem. Even though I see a lot of advantages with having parameters because then you can change behavior on a per transaction basis.

Updated