CIBA: acr/amr alignment

[Dave Tonge]

The CIBA core profile says this about acr:

OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the OpenID Provider is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The actual means of authenticating the end-user, however, are ultimately at the discretion of the OP and the Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value of the ID Token. When the acr_values parameter is present in the authentication request, it is highly RECOMMENDED that the resulting ID Token contain an acr Claim.

FAPI RW goes quite a bit further with this:

• 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 require JWS signed ID Token be returned from endpoints;
• 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;

Should we bring the FAPI CIBA profile into alignment with FAPI RW? Are there any issues with this?

[Ralph Bragg]

My concern is the LoA3 requirement - typically this would be good enough to bring a Criminal Case not just a civil case against the holder / user of the credentials. This isn't achievable for payments in the vast vast majority of use cases.

It's one of the areas where OB have to drop it to L2. whilst we're here can we look at VoT standardization?

[Dave Tonge]

Yeah I'm also a bit concerned about the normative language we have re LoA3. I think it makes too many assumptions on an ecosystem. We should definitely discuss this on the next call.

[Joseph Heenan]

The two clauses on the client:

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;

essentially require that the AS must return acr and amr in all id_tokens (as they are requiring the client to reject the response if acr/amr are missing). We should probably list that requirement in the AS section.

(I don't think any UK banks are returning amr currently, and several fail to return acr even when explicitly requested as essential.)

[Ralph Bragg]

if they're not returning ACR then they're in breach of the current OB Security profile. :( We require banks to return either SCA or CA as the ACR value that was used. All other provisions stay the same as core OIDC 5.5.1.1. Requesting the "acr" Claim

[Dave Tonge]

So looking into this more - the ACR requirements we have are for public clients. I'm going to close this as CIBA is actually in alignment with FAPI and OIDC

[Joseph Heenan]

The ACR requirements in FAPI-RW apply to confidential clients too

[Dave Tonge]

Good catch @josephheenan

Do you think we should tighten the requirements in CIBA?

[Joseph Heenan]

@dgtonge I was perhaps more thinking about weakening part 2 as per Ralph comments - I split that out into another ticket:

https://bitbucket.org/openid/fapi/issues/218/loa3-requirement-in-part2-may-be-too-much

The potential issue I see with CIBA currently is it has no mechanism to request an ACR as essential. I don't know how important this is. It seems like in the EU PSD2 doesn't require the banks to allow essential ACR claims. (i.e. a TPP can't insist a bank does SCA, nor can they insist a bank doesn't do SCA).

It seems a bit odd to me, and potentially against the data minimisation principle of GDPR - ie. if a TPP will not go any further if there's no SCA, it makes no sense to return an id_token to the TPP.

I think for practical purposes, if we weaken the ACR requirements in FAPI-RW then FAPI-CIBA is likely fine as-is.

[Dave Tonge]

I’m leaving this issue open until we sort out #218

[Joseph Heenan]

I’ve raised a pull request for FAPI-RW here:

‌

https://bitbucket.org/openid/fapi/pull-requests/115

‌

If this is accepted, we may want to;

‌

1. Add a similar statement to FAPI-CIBA
2. Given the lack of a mechanism for requesting an acr claim as essential in CIBA, I’d suggest FAPI-CBA change ‘recommended’ to ‘shall’ for the ‘When the acr_values parameter is present in the authentication request, it is highly RECOMMENDED that the resulting ID Token contain an acr Claim.’ clause in CIBA core.

[Joseph Heenan]

I have opened a pull request with wording along the lines of my previous comment, to try and driving this issue to a conclusion one way or the other:

‌

https://bitbucket.org/openid/fapi/pull-requests/123/ciba-bring-acr-behaviour-into-line-with/diff

[Dave Tonge]

CIBA: Bring acr behaviour into line with part 2

Apply the suggested changes to part 2 to the CIBA spec.

closes #201

→ <<cset d8d4fd629f6a>>