1.   Roll Call (Nat)

• Attendees: Nat, Joseph, George, Aaron, Bjorn, Brian, Craig, Daniel, Dave, Dima, Justin, Kosuke, Mark
• Regrets:

2.   Adoption of agenda (Nat)

• Adopted as is.

3.   Events (Mike L.)

4.   Liaison/Ext Org (Mike/Chris)

5.   PRs (Dave)

• PR 429 - fixes #527 - Create security note/consideration on B. Access Token Injection

  • https://bitbucket.org/openid/fapi/pull-requests/429
  • Merged but opened a related ticket.

• PR 431 - Proposal to fix Issue #617

  • https://bitbucket.org/openid/fapi/pull-requests/431
  • Waiting for Taka's approval

6.   Issues (Dave)

• #608 Make clear that requests and responses to resource servers don't have to be bound

  • Make it clear to only sign the request signature and request signature input if applicable (i.e. if present) also add to the note to explain further
  • Created #625 in relation to this issue.

• #622 Review FAPI1 security considerations for clarity

  • Make sure that not all security considerations need to be implemented.

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

  • concluded not to make the jws algorithm part of the profile matrix at all, same as it wasn’t part of the matrix in FAPI1.
  • This is more for vendor product certification - if folks have ideas, it will be welcome but this ticket is being closed.

• #619 Authentication property of FAPI 2.0

  • Daniel suggests that it would be a functional property.
  • It might be good to point it out in the implementation guidance.
  • Nat to come back to it after refreshing memory.

• #617 Security issue in the JWT Response for OAuth Token Introspection specification

  • No discussion

• #618 Certification/conformance: Strictness of checking error responses

  • 40x response checking in particular from PAR endpoint.
  • A screenshot in the certification request would suffice.
  • To be closed.

• #602 "Client" is misleading in the context of signed introspection responses

  • Taka pointed out that it is linked to #617.
  • Once Daniel's PR is approved, it should be resolved.
  • The PR: https://bitbucket.org/openid/fapi/pull-requests/431

• #457 Create JSON Schema for Grant Management Specification

  • Grant management did not get adopted by AU so it has no time pressure.
  • To be kept in our backlog.

• #603 Require servers to allow for clock skew

  • At least 10 sec, but not more that 60 sec.
  • George: How does a client know it failed due to clock skew? Being specific may limit the applicability.
  • Joseph: Lower bound was introduced to testable.
  • George: Would it not be better to make it a conformance testing requirement and not normative?
  • Joseph: That would confuse people.
  • George: Depending on the risk environment and functional protocols, we may want to further lockdown or relax.
  • Joseph: Lowerbound as "shall" and upperbound as "should"?
  • George: With a security consideration, pointing out the possibility of changing the bounds, OK.
  • Brian: For time-syncing, we can use nonce in DPOP.

7.   AOB (Nat)

• n/a

The meeting adjourned at 15:00.