1.   Roll Call (Nat)

• Attendees: Nat Sakimura, Arnaud Bruyer, Mike Leszcz, Robert Gallagher, Joseph Heenan, Peter Wallach, Lukasz Jaromin, Daniel Castillo, Mark Andrus, Dave Tonge, Daniel Fett, Dima Postnikov, Takahiko Kawasaki, Chris Michael, Kosuke Koiwai, George Fletcher, Domingos Creado, Craig Borysowich
• Regrets:

2.   Adoption of agenda (Nat)

• Adopted as is.

3.   Events (Mike L.)

4.   Liaison/Ext Org (Mike)

5.   PRs (Dave)

• PR #430 - fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported
  • Not sure about allow front channel access tokens
  • PKCE is required but asking for access token in front channel is still using PKCE
  • Intent was to not allow front-channel access tokens
  • Currently, there are not many implementations of FAPI 1 part 1
  • PR proposal to required ‘code’ as one of the response_type values allows front -channel access tokens which is not the intent
  • Being silent seems to allow front-channel access tokens implicitly
  • Being explicit of the intent is more useful
  • Certification suite does not test for FAPI1 Baseline
  • Could put in the intent instead of explicit text regarding response_type values
  • Did not make response_type ‘code’ and ‘code id_token’ explicit but PKCE requirement is explicit
  • PKCE is used to protect the code and access token exchange
  • Delivering access token in the front-channel bypasses PKCE protections
  • Proposed to restrict response_type to ‘code’ or ‘code id_token’, but this may go beyond the scope of an errata.
  • PKCE is required but is not clear whether implicit flow is allowed, but PKCE is meant to protect code/access token exchange so it is not a normative change, but editorial/clarification one.
  • Security analysis assumes code flow only
  • Nat/Daniel added comments to PR and issue
• PR #429 - fixes #527 - Create security note/consideration on B. Access Token Injection with ID Token Replay (FAPI 1.0 Advanced)
  • Updated PR to use OIDD or RFC8414.
  • Change “can be mitigated” to “are mitigated”.
  • FAPI1 part 1 5.22. and 5.2.3 explicitly requires use of AS metadata.
  • New section overlaps with 8.3.5

6.   Issues (Dave)

• #618 - Certification/conformance: Strictness of checking error responses
  • Some negative test cases that test security properties
  • Some clients returned different error codes than specified
  • The certification team is asking if the error code conditions should be relaxed
  • Some conformance tests that are unrecoverable at the authorization endpoint and which result in a error displayed have been relaxed so this seems uncontroversial
  • The cases to relax these restrictions are cases where the client cannot recover from and normally do not happen in production systems
  • Allow multiple error codes will have implications for clients and libraries
  • Clients have no way to know in which cases to relax error codes
  • AS should not return different code than spec allows
  • Issue arose due to a bank trying to certify FAPI deployment but changing AS software is complicated
  • Conformance suite has a range of warning results that are not hard pass/fail
  • Could have different degrees of warnings
  • E.g. misconfigured clients which usually do not happen on production systems is not too concerned with actual error code
  • Situations where clients can recover at runtime must fail if wrong errors are returned
  • If best practice is to display an error, anything that does not display an error is a warning
  • Conformance suite has allow both options a) display error b) return error code
  • Warnings should have details of why warnings were issued
  • Trying to discern whether clients can recover from an error can be very subjective
  • E.g. MTLS client authentication either succeeds or fails and clients cannot automatically recover
  • Propose to go with the more restrictive case and decide on case by case basis
• #617 - Security issue in the JWT Response for OAuth Token Introspection specification
  • Could allow clients to introspect access tokens for other client applications
  • Privacy/security considerations of JWT response do not mention this possibility
  • JWT Response for OAuth Token Introspection is in publication queue so it cannot be changed
  • Could add security considerations to our JWT spec
  • WG can add constraints in profiles
  • AS needs to distinguish between RS and clients
  • Introspection endpoint is loose on authorization policy
    • Is caller allowed to access the endpoint
    • Is caller allowed to introspect the presented token
  • Allowing clients to introspect tokens for other clients can be managed via metadata on backend
  • Daniel will try to add security considerations
• #602 - "Client" is misleading in the context of signed introspection responses
  • Related to #617

7.   AOB (Nat)

The meeting adjourned at 14:55.