3.1.   OAuth Security Workshop

Rome April 10-12 – final call for speakers is open until March 10th.

All details here: https://oauth.secworkshop.events/osw2024

3.2.   OIDF Workshop at Google

on Monday, April 15th in Sunnyvale – registration now open and required: https://openid.net/registration-oidf-workshop-monday-april-15-2024/

3.3.   The OpenID Foundation DCP working group

WG is hosting a hybrid meeting on Friday, April 19, 2024 after IIW Spring 2024. The meeting will allow for in-person and virtual participation and will be hosted at Google in Sunnyvale, CA (address and meeting room to be confirmed). Note that registration is only required if you are attending in-person:

https://www.eventbrite.com/e/openid-foundation-dcp-working-group-hybrid-meeting-tickets-841453930357?aff=oddtdtcreator.

Please register if you are planning to participate in-person so we can plan accordingly.

3.4.   Identiverse

May 28-31, Las Vegas

OIDF has a meeting room available for use for the duration of the event

Any working groups wanting to hold a F2F meeting should contact Mike Lescz to coordinate.

4.1.   Brazil

OFBR – continued high volume of FAPI re-certification requests to meet central bank mandates/milestones.

Certification team is doing an excellent job in managing the increased volume.

OPIN – starting to see next phase of FAPI re-certifications

4.2.   EAU - (United Emirates)

Joseph, Mike, Gail will have follow up call tomorrow regarding FAPI2 implementation plans and milestones

4.3.   FDX

Joseph and Mike will be presenting

Will also meet with FDX leadership and Ernst and Young representatives

Awaiting for draft rules to be published

4.4.   Fintech Summit Tokyo

Nat held an open banking panel

10,000 people attending

Jason (FDX) mentioned that Canada regulators are mandating uniform API specifications and certifications

5.1.   PR 474 - Fixing #638 - Add some more text to Introduction

• PR #474, #638
• Add information regarding FAPI2 specifications in the series and mentions Attacker Model for reference
• There are 2 introduction clauses in the document due to ISO document requirements
• Need to make them more consistent
• Nat will update

5.2.   PR 463 Fixes #653 - Update abbreviated terms

• PR #463 - https://bitbucket.org/openid/fapi/pull-requests/463
• To be merged

5.3.   PR 475 First draft for MTLS ecosystems

• PR #475 - https://bitbucket.org/openid/fapi/pull-requests/475
• First draft text was provided by Dima.
  • Objectives
    • Note on how current ecosystems use MTLS differently
    • Discovery of endpoints and aliases that may have MTLS and non-MTLS endpoints
• Feedback from Filip and Joseph.
  • Require client metadata registration in IANA section to be configured to look for MTLS aliases
  • Update sections regarding MTLS for clients referencing the new metadata information
  • Conference suite does not use DCR so may need to add a configuration option
  • May have to add a conformance profile with MTLS protections that can be applied to multiple ecosystem profiles to simplify conformance testing/configuration
  • Server metadata for ecosystems that require MTLS doesn’t make sense. Such ecosystems should use root endpoint metadata
• There is also a comment from Tom on the issue #670. Dima will touch base with him.
• Dima will amend the text.

5.4.   PR 476 - add wording for state and nonce

• PR #476 - https://bitbucket.org/openid/fapi/pull-requests/476
• Support min of 512 for state
• Support min of 64 for nonce if using OIDC
• State is opaque to the AS but only allows printable ASCII in RFC6749
• Conformance tests do not test for non-ASIII characters due to various issues requiring diagnosing
• Add “For interoperability” and “up to XXX length”
• Conformance test will change to test acceptance of 512 characters for state and 64 for nonce
• Add wording for clients “states less than 512”
• Dave will update

6.1.   #660 Define requirements for OpenAPI FAPI securityScheme type

• #660
• There is no sensible way to express a security scheme in OpenAPI right now.
• This ticket is suggesting to create a document so that it can be proposed to them.
• This does not impact the spec so the spec can proceed independently.
• Peter Stanley supported it, mentioning that OpenID Connect is a scheme there.
• Assigned to “Others” component

6.2.   #651 Avoid "should be" and "shall be" where possible

• #651
• Make authorisation server and/or clients etc. as the subject of the sentence.
• Dave is going to make a PR for the call next week.

6.3.   #642 Continuation of #619 -- Add some text to make the readers aware of the caveats.

• #642
• Issue linked to #638

6.4.   #656 - Create terms and definition as well as the abbreviations for the attacker model document

• #656
• Nat will respond to Daniel’s proposal in comment
• Attacker Model has clause titles with General (Review title) needs review/updating
• Nat will create a new issue to address clause titles

(to be continued)