1.   Roll Call (Nat)

• Attendees: Dave Tonge, Joseph Heenan, Nat Sakimura, Arnaud Bruyer, Peter Stanley, Michael Palage, Peter Wallach, Craig Borysowich, Fabio Szescsik, Mark Andrus, Domingos Creado, Daniel Fett, Kosuke Koiwai
• Regrets: Mike Lesczc,

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
  • requires response_type = code or code id_token
• PR #429 - fixes #527 - Create security note/consideration on B. Access Token Injection with ID Token Replay (FAPI 1.0 Advanced)
  • • There is concern that mentioning at_hash as a possible mitigation can be misread as a requirement
  • ID Token is not required so at_hash can be read as requiring an ID Token
  • Joseph will review and suggest possible wording
  • FAPI 2 only returns ID Token from token endpoint and is not relied upon for any security property
  • OIDC allows ID Token in front-channel for UI performance
  • Some ecosystems do not want to return PII via browser
  • ID Tokens in FAPI 1.0 which contain PII should be encrypted. Not all PII need to stringently managed
  • Sub in ID Token can be sensitive PII depending on it’s value / context
• PR #417 - ciba refactor to support FAPI2
  • Dave is working on addressing comments from Tim.
  • Signed requests are optional
  • Update normative references
• PR #431 - Proposal to fix Issue #617
  • There is confusion regarding resource server as clients and regular client in the introspection request
  • Brian proposed some text
  • Taka will review and Daniel will make updates to PR

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
• #620 - Request for clarification on fapi1-advanced-final-par-pushed-authorization-url-as-audience-in-request-object test case
  • Probable confusion as result of link to wrong spec in the conformance test.
  • Conformance test has fixed the wrong reference
  • Issue will be closed
• #617 - Security issue in the JWT Response for OAuth Token Introspection specification
  • There is some existing text in some spec which covers this case, but it would be helpful to add additional clause by Daniel
• #619 - Authentication property of FAPI 2.0
  • This issue is a result of some issues/scandals in Japan regarding national identification card
  • How does security analysis deal with the authentication property of FAPI 2.0?
  • Does it assume correctness of user authentication?
  • It’s borderline between security property and functional correctness
  • Not sure whether it will be addressed by FAPI 2.0 or will be a security consideration
  • Authentication property as currently defined is not broken by attack but maybe confused
  • FAPI 2.0 does not require OIDC so ID Tokens are not required which may prevent such confusion
  • Add security consideration regarding some mitigations by getting access to persistent subject identifiers
  • UK does not use persistent identifiers
  • Australia uses persistent PPIDs
  • In cases where there are no persistent user identifiers, user will have to go through the consent flow
  • It might be a good use case for grant management but it’s the authorization service’s decision when to reauthorize
  • Available resources can change when reauthorized
  • Risks associated with reauthorizations should be added to security considerations

7.   AOB (Nat)

The meeting adjourned at 14:55.