-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2024 03 20_Atlantic
- Date & Time: 2024-03-20 14:00 UTC
- Location: https://zoom.us/j/97456084642?pwd=bTRFVzk4ZmlRK1M3bEprRlN5c3JFZz09
Agenda
- 1. Roll Call (Dave)
- 2. Adoption of agenda (Dave)
- 3. Events (Mike L.)
- 4. External Orgs & Liaisons (Mike L.)
-
5. PRs (Dave)
- 5.1. 475 - First draft for MTLS ecosystems
- 5.2. 480 - fapi-2_0-security-profile.md edited online with Bitbucket
- 5.3. 474 - Fixing #626 - Add some more text to Introduction
- 5.4. 479 - change this specification to this document - for ISO
- 5.5. 478 - make security considerations top level
- 5.6. 476 - add wording for state and nonce
- 5.7. 477 - improve wording to remove shall be
- 6. Issues (Dave)
- 7. AOB (Nat)
The meeting was called to order at 14:05 UTC.
- Attendees: Joseph Heenan, Nat Sakimura, Daniel Fett, Dima Postnikov, Kosuke Koiwai, Dave Tonge, Bjorn Hjelm
- Regrets:
Coming up on Mar 16 - 22. Brisbane
https://datatracker.ietf.org/meeting/119/agenda
Rome April 10-12 – final call for speakers is open until March 10th.
All details here: https://oauth.secworkshop.events/osw2024
on Monday, April 15th in Sunnyvale – registration now open and required: https://openid.net/registration-oidf-workshop-monday-april-15-2024/
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:
Please register if you are planning to participate in-person so we can plan accordingly.
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.
FAPI WG will hold F2F
Identiverse agenda has been announced on website
OIDF calendar on website is current: https://openid.net/calendar/
- Coordinating the call with regulators
- Had a call with a bank with Mark Haine. They are still wondering whether to go to 2.0.
- May go live in 2025
- VC issuance vote going on.
- https://openid.net/foundation/members/polls/328
OFBR + OPIN – continue to process FAPI re-certification requests.
The certification team has posted a Java developer opportunity and is actively recruiting:
https://openid.net/certification-program-recruiting-java-developer/
- The first draft should come out tomorrow. FAPI2 w/private key JWT client authentication, MTLS sender constrained access tokens, RAR, signed request objects
- Liaison statement is to be sent.
- Info about FAPI 2 that it is close to final. Send the drafts.
- Also mentioned that it is getting adopted in some jurisdictions and growing number of implementations and certifications
PR #475
Dima updated but Ralph request other updates
Will coordinate meeting with Ralph, Brian, Mark from DSP in Brisbane
PR #480
editorial edits
Will merge
5.3. 474 - Fixing #626 - Add some more text to Introduction
PR #474
Awaiting PR
PR #479
Editorial text change from “specification” to “document”
May conflict with OIDF IPR notice text
IPR text to remain unchanged
PR #478
Changes will affect clause numbering
Note regarding refresh token rotation refers to clause 10, should be 5.3.2.1-10
PR #476
Explicit support for state values up to 512 and nonce values up to 64
Will merge
PR #477
Looks fine
Need to fix typo
Joseph questioned whether we need “shall only” for serving JWK since supporting both HTTP and HTTPS is still compliant
Change to “shall only serve the jwks_uri over TLS”
Conformance suite does not validate typ values
Some Brazil banks rejected objects with typ values
Specs are not clear, only JAR mentions it but there is no normative text
Proposed putting some validation for typ values in OP and RP tests
Proposes testing for JWT, oauth-authz-req+jwt, and absent value
Brian suggested to drop JWT value since it’s meaningless. Should not disallow it but also not encourage its usage.
There are various uses for JWTS but typ value may help mitigate type confusion according to BCP
Makes sense to be as strict as possible
JAR recommends requiring explicit typ values for new OAuth deployment profiles where compatibility is not a consideration
Will affect Message Signing, PAR with JAR
WG agrees to make requirement for clients to use “oauth-authz-req+jwt” and AS to reject if not present
Need resolution for FAPI1 conformance tests
=> Check OP accepts recommended value and RP not sending unacceptable values for interoperability, AS should also accept “JWT”
Will discuss further
FAPI2 SP requires 160 minimum bits but ES256 and EdDSA (Ed25519) uses 256
FAPI1 requires 160 minimum
Text seems to be about key length for JWTS instead of TLS
TLS BCP requires 224
Suggested requiring 3072 for RSA and 256 for EC
Conformance suite does not test TLS keys size
Agree to require 224 for EC
Need more input regarding move to 3072/256
6.3. 642 - Continuation of #607 -- Add some text to make the readers aware of the caveats.
Addressed in Attacker Model
Nat will confirm
n/a
The meeting adjourned at 15:04.