Behaviour of AS undefined if no acr claim supplied by client

[Joseph Heenan]

FAPI part 2 says:

Part1. 5.2.3. public client 3. shall request user authentication at LoA 3 or greater by requesting the acr claim as an essential claim as defined in section 5.5.1.1 of OIDC;

There's no corresponding requirement on the server.

As far as I can tell every openbanking implementation supplies a default if the client doesn't pass an acr claim.

By contrast the current implementation of Authlete shows an error to the user in this case.

(We discovered this as the FAPI conformance suite we've been working on does not currently supply an acr claim due to an oversight...)

It may be worth being more explicit about how the server should handle this case to improve interoperability.

[Nat Sakimura]

We still need more investigation on this one, but the call on Aug. 2 pointed out several things:

• The client, where it was exempted, should be able to ask for a lower level authentication, e.g., single-factor authentication to improve the U/X. This kind of use-case is not covered by 5.5.1.1 of OIDC Core.
• Even if the client asked for LoA 3 or something, it is at the Bank's discretion to perform a lower LoA authentication as the responsibility falls onto Banks anyways. (This is in contrast to many existing identity federations.)

[Tom Jones]

all three parties to an interchange are free to change most of the scopes/claims. The client can ask for the moon - according to both EU & CA law they should be specifying which scope/claim is required. That should be an issue, but I suspect in core and not here.

The user can (or should be able to) select which scope/claim to provide.

The OP should be required to honor the user wishes (unfortunately the consent is optional - bad idea) The OP can provide whatever level of assurance (and other claims) it wants.

The client can reject the result - this case is not well documented - it seems like the only option is failure, but that is poor UX. It will probably be an interesting test case of the open banking in both uk & eu when the psp sues the bank for non compliance. It seems that they should be able to sue the bank for not properly authenticating the user if they lose money as a result.

[Ralph Bragg]

On this topic - providng ACR is mandatory for OB. The mechanisms are already there however to do everything that's described by tom and nat. I do think that for FAPI we should be always returning ACR. Potenitally we should also be looking to include vectors of trust.

ASPSPs are fundamentally responsible for customer authentication and authorization and are free to apply a risk based decision to the level of authentication required for the given request in order to innovate the customer security experience. TPP’s are free to optionally request ASPSP’s perform a specific level of authentication by providing an array of acr_values that they would like an ASPSP to perform as part of the signed authorization request in order of most desirable to least desirable. TPP’s are free to demand an authentication level from the ASPSPs during authentication by setting the acr property of the signed authorization request however ASPSPs are under no obligation to fulfil that level and will fail the authorization request in line with OIDC standards. ASPSPs must always notify the TPPs of the course grained “level of authentication” that the ASPSP felt it performed providing it as a mandatory claim. ASPSPs may provide vectors of trust information that further describes the identity confidence the credentials used to meet the level of authentication obtained.

[Tom Jones]

innovate the customer security experience???? Does that include confusing and misleading the customer? I have no faith that people trying to take money from my account will be much concerned with my welfare.

[Nat Sakimura]

FAPI part 2 says:

Part1. 5.2.3. public client 3. shall request user authentication at LoA 3 or greater by requesting the acr claim as an essential claim as defined in section 5.5.1.1 of OIDC;

There's no corresponding requirement on the server.

As far as I can tell every openbanking implementation supplies a default if the client doesn't pass an acr claim.

By contrast the current implementation of Authlete shows an error to the user in this case.

(We discovered this as the FAPI conformance suite we've been working on does not currently supply an acr claim due to an oversight...)

It may be worth being more explicit about how the server should handle this case to improve interoperability.

[Dave Tonge]

We removed the ACR requirement