3.1.   OSW 2022 (Daniel)

May 4 - 6 @ Trondheim In-person only

https://oauth.secworkshop.events/osw2022

Event is now sold out

3.2.   EIC/OpenID Foundation Berlin Workshop (Mike)

May 10, Tue.

https://www.kuppingercole.com/sessions/5048/1

3.3.   Identiverse

Denver, Colorado June 21-24, 2022

https://identiverse.com/

4.1.   Certification (Joseph/Mike)

5.1.   Australia (Mike L.)

5.2.   Brazil (Mike L.)

5.3.   Berlin Group (Daniel)

5.4.   EU DIW ARF (Gail)

• n/a

5.5.   FDX (Rifaat)

5.6.   GAIN (Dima)

Group is still forming

Looking at different options for trust management

• How to trust participants from different ecosystems
• How to determine the level of trust and level of participation in the network

FAPI is used together with eKYC for identity assurance

5.7.   IETF OAuth WG (Rifaat)

Call for adoption for the Step Up Authentication draft by Brian and Vittorio

5.8.   ISO/TC68 (Nat/Dave)

• n/a

5.9.   The Middle East and North Africa (Chris)

• n/a

5.10.   Mexico (Gail)

• n/a

5.11.   Nigeria (Mike)

5.12.   OECD (Nat)

• n/a

5.13.   UK (Chris)

• n/a

5.14.   USA (Gail)

• n/a

6.1.   Grant Management (Dima)

Will work on issues at OSW and EIC

6.2.   FAPI DCR/M (Dynamic client registration and Management) (Joseph)

• N/A

6.3.   Advanced authorization (Dima)

6.4.   FAPI 2 Attack, Baseline and Advanced (Daniel)

• N/A

6.5.   JARM (Dave)

8.1.   #493 - certification query: supply of TLS client certs & use of mtls_endpoint_aliases

#493 - certification query: supply of TLS client certs & use of mtls_endpoint_aliases

It’s about mtls_endpoint_aliases and how that works and certification

It’s problematic when used with ecosystems and PAR

In UK, banks all have MTLS protected endpoints

FAPI required MTLS sender constraining at the token endpoint

There are doubts on when mtls_endpoint_aliases should be used if MTLS is required on top of private key JWT

Client behavior is not defined

Some view that MTLS is just a transport layer and the client should not need to care

If there is a need to use MTLS and non-MTLS endpoints, there is no need to use mtls_endpoint_aliases

Problem can be solved by mtls offload proxies

Not sure how to implement the conformance test due to uncertainty

Current 3 FAPI ecosystems are requiring MTLS everywhere, will be problematic if each uses different approach for using mtls_endpoint_aliases

Should be treated as transport layer

Should FAPI 2 Advance have a use case for using MTLS everywhere and add a note on how to interpret the use of mtls_endpoint_aliases?

Joseph will summarize the issue and draft a PR with note.

8.2.   #495 - Certification: Requirements for alg support in RPs/OPs

#495 - Certification: Requirements for alg support in RPs/OPs

Should certification reflect support for the various algs? Doing so will allow discovery of problems with various algs but will make certification tables unwieldy. There will be a presentation problem.

If certifying for Eddsa, will have to support DPOP, private_key_jwt and OpenID

Google has a crypto test suite with tests vectors for testing correct implementation

Could add some of those tests into the certification suite.

Should FAPI tests the JOSE specs as much as possible?

Doing so could add lots of complexity.

There is no clear line of distinction on what should be tested at which level.

Should the certification suite be responsible for testing them?

Joseph and his team to investigate and summarize the issue.

Testing every possible combination is impossible but maybe a few select tests.