4.1.1.   What shall we token bind?

The WG group discussed what needs to be token bound. If the server and the client supports token binding, then it should token bind refresh token and access token.

Question: Shall we token bind code as well?

Nat asked John to provide an example of token binding messages, which are not in the token binding specs. John agreed.

4.1.2.   Would there be other options?

Yes. We will still have mutual TLS auth available. Token Binding may take longer time to get implemented. Sascha expressed that something that can be completely application layer is easier to implement. Nat expressed that he needs something that API GW vendors can support. Sascha agreed to look into the matter and report back on the token binding support and alternatives.

4.1.3.   Authentication Requirement

WG discussed what format shall be used to express the authentication requirement. John pointed out that iGov is coming up with vectors of trust expression. Nat pointed out that it would be best to align and asked John to make a presentation on iGov decision next week. John agreed.

4.1.4.   Always Request Object?

There can be two types of interactions with the user.

• type 1: The client makes the "write" request (e.g., initiate payment) in the authorization request to get user authorization. This is a typical case in many of the payment schemes.
• type 2: The client makes the "write" request to a specialized API so that the API can send the user notification and get authorization. This is something Modrna is working on.

In type 1 case, authorization request should be signature protected: i.e, has to be a request object, otherwise it may be tampered in browser.

In type 2 case, there is no authorization request involved but some other API calls (Editors note: which again may be needed to be signature protected for the recording purposes etc.)

Nat asked John to make the presentation on Modrna user questioning API next week. John agreed.