1.1.   Attending:

1. Nat
2. Brian
3. Dima
4. Joseph
5. Kosuke
6. Ralph
7. Stuart
8. Dave
9. Bjorn

1.2.   Regrets:

3.1.   ISO/TC68/SC2/SG2 Security aspects of bar code payment (Nat)

Their first meeting is scheduled to be tomorrow. Nat did not see any WG members to be in the roaster but suggested that somebody working on CIBA may be interested to it that they can join the group through their respective National Bodies. Alternatively, FAPI WG could open a liaison with this new group but that will take some time before getting approved.

The group's web page is here:

• https://www.iso.org/committee/49670.html

3.2.   Australia (Dima/Stuart)

New consent request is going around. Folks that are interested should weigh-in.

• https://github.com/ConsumerDataStandardsAustralia/standards/issues/85

Certification team compiled the document listing the differences between the current FAPI specs and Australia.

• https://docs.google.com/document/d/1_reJVmWSxIyeKm2yGFN2cAP9BcWYsT7XosNbLYk4D0Y/edit

Some changes previously noted seems to be fixed. There are changes that may cause interoperability issues however and we need to understand why they are made. For example, requiring that iss SHALL NOT be in the request object. The rationale seems to be save something like 20 bytes in the request object for the concern of the request object size but if the size is the concern, using request_uri is a preferred method in FAPI. In any case, we are just guessing the rationale and that is not really productive so we should clarify those in the forthcoming call.

Related to it, Stuart asked about the Mix-up Attack mitigation and the relationship between client_id and iss. Nat answered the question.

Dima also pointed out that another topic is being raised in CDR. People are asked to read it.

• https://cdr-register.github.io/register/#client-registration

3.3.   UK Open Banking (Ralph)

Interest on CIBA building up. There was a hack-a-thon at SIBOS.

4.1.   PR #142 Refresh Token (Joseph)

Joseph proposed a new wording on the call and there was a friendly amendment on it by Brian. Joseph is going to make a modified PR based on it so that people can review the concrete wording.

5.1.   #270 JARM (Joseph)

In the non-openid cases where scope does not include openid, "nonce" does not make sense. However, just requiring "state" is likely to be understating what the clients need to be doing to thwart CSRF etc. Callers agreed that requiring PKCE may be a better way to go. Folks should comment on the ticket of their opinions.

5.2.   #263 Refresh Token (Joseph)

See PR #142

5.3.   #251 refresh token expiry time (Joseph)

There seem to be two ways of returning it and UK and Australia are going to a different direction. It may be interesting to find out what is the current majority practice by taking a survey at IIW.