Error/non-error handling in case OP cannot fulfill RP requirements

[Torsten Lodderstedt]

What is the behavior of the OP in cases, where the OP cannot fulfill the RPs requirements regarding authentication? Example: RP potentially only bought LOA3 and not LOA2 - what should happen?

Discussions during workshop: - if it can be determined before the authentication happens -> error - if the authentication process is already in progress -> conduct authentication and attest identity along with information about the (less strong/different) authentication method(s) performed

[Jörg Connotte]

That's an interesting one. Should MODRNA make assumptions about OP policies or leave it to the OP how to handle operational constraints?

[Jörg Connotte]

In principle there is a mechanism already in place to force an error if the right acr can't be performed by the OP. http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics

Further discussion is needed to decide if this mechanism is sufficient or a stronger prolicy specification is necessary.

[Jörg Connotte]

The specifications done in https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics give the RP sufficient control. Imposing policy rules for the OP should not be reflected in the specification.

[Joseph Heenan]

@Eisiphone I don't think I fully understand this conclusion.

https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics talks about the semantics of the acr claim.

As CIBA only supports acr_values (and not the acr claim, as per discussion on https://bitbucket.org/openid/mobile/issues/103/ciba-means-to-require-acr-as-essential ) I cannot see the relevance of https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics to CIBA as that section is talking about the acr claim.

As far as I can see, an RP using CIBA cannot request that the AS errors out if the requested ACR cannot be achieved. It is also not possible to achieve this functionality within the RP, as the AS is not required to return the ACR used to the RP. (It is recommended that the AS does return it, but it is not required so the RP cannot rely on it.)

[Joseph Heenan]

To add to my previous comment, I believe the current situation means that the FAPI profile of CIBA will need to add an acr claim to the protocol, as FAPI-RW requires the client to make an essential acr claim, and requires the client to verify the acr in the returned id_token is correct - neither of which are possible in CIBA core.

[Torsten Lodderstedt]

We may need to reconsider this requirement. Can you please explain why the client is supposed to request a certain authentication level? I think the AS should do based on the authorization the client is asking for. For example, under PSD2 it’s clear (regulated) when a bank (AS) needs to conduct SCA (MFA).

[Joseph Heenan]

I'm not sure I can explain why, we may need @Nat for that!

I can expand though; https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md requires that RPs:

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;

shall verify that the acr claim in an ID Token indicates that user authentication was performed at LoA3 or greater;

shall verify that the amr claim in an ID Token contains values appropriate for the LoA indicated by the acr claim;

I'm not sure how LoA3 maps onto PSD2 SCA. It may be that the above statements in FAPI-RW are not entirely consistent with PSD2 allowing SCA exemption?

OpenBanking in the UK ran into a bit of a mess trying to figure out how to map what they thought PSD2 said at the time on to the OIDCC acr and acr_values, I'm not sure if they ever resolved that.

[Torsten Lodderstedt]

My point is: who decides what authentication level is needed for a certain authorization? my opinion: it‘s always the AS That is different in OpenID/Federated Identity scenarios but we are talking about API authorization at FAPI.

[Joseph Heenan]

I am not 100% sure, but I have previously been told that under PSD2 the third party is able to request(require) that SCA is performed even for a transaction that might be exempt.

[Torsten Lodderstedt]

Never heard about that. The ASPSP has the final say.

[Bjorn Hjelm]

If you could help with clarifying the requirements for third-party requesting SCA per PSD2, that would help addressing your comments. Per Torsten's comment, the working assumption has been that the AS requests the authentication level.

[Joseph Heenan]

I'm pretty much failed to get any official guidance from OB UK on how acr values should be handled. I've not found any evidence to backup my assertion that the TPP is able to insist on SCA, so Torsten does appear to be correct on that point, it's up to the ASPSP.

I'd suggest it's probably best to follow up on this on the FAPI WG ticket on the similar subject: https://bitbucket.org/openid/fapi/issues/201/ciba-acr-amr-alignment