LoA3 requirement in part2 may be too much

[Joseph Heenan]

https://bitbucket.org/openid/fapi/issues/201/ciba-acr-amr-alignment mentions the current LoA3 requirement in part 2 not reflecting what actually ends up happening at least at OB, e.g. these two comments:

Ralph said:

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?

and Dave said:

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.

I don't remember if we did actually discuss this on a call (and I can't find a ticket about it, the above ticket is about CIBA), so opening this ticket so it doesn't get lost.

[Joseph Heenan]

https://bitbucket.org/openid/fapi/issues/201/ciba-acr-amr-alignment mentions the current LoA3 requirement in part 2 not reflecting what actually ends up happening at least at OB, e.g. these two comments:

Ralph said:

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?

and Dave said:

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.

I don't remember if we did actually discuss this on a call (and I can't find a ticket about it, the above ticket is about CIBA), so opening this ticket so it doesn't get lost.

[Joseph Heenan]

Discussed on today’s call: LoA3 is felt to be a bit strong, and the ‘must’ on sending acr claim is unnecessary in some ecosystems.

I’m going to come up with some suggested wording that replaces the requirements with text more along the lines of “the AS must ensure a sufficient level of authentication is carried out based on the operation the client has said it wants to perform” and “the client must ensure that the AS have authenticated the user sufficiently for client’s purposes”, but to not dictate the technical details of how that is done.

‌

(Hopefully that’s a reasonable summary of a fairly long conversation)

[Joseph Heenan]

Nat wrote a more comprehensive summary of the above conversation in the minutes: https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2019-06-05_Atlantic.rst

[Joseph Heenan]

Pull request with my suggested wording opened at https://bitbucket.org/openid/fapi/pull-requests/115/fapi-r-rw-bring-clauses-about-acr-inline/diff

[Nat Sakimura]

FAPI-R/RW: Bring clauses about acr inline with usage

FAPI-R/RW currently contain various clauses about acr and amr, which we're not seeing actually used seriously in deployments of FAPI.

The 'amr' clause has, as far as I know, never been applied.

The 'acr' and LoA3 requirements differ from what it actually applied, and are really something for an ecosystem to define rather than a standard.

The clauses are distilled down to their core underlying statement, i.e. that both the authorization server and the client must make sure they're level of confidence they have in the authentication is appropriate for their purposes.

Ecosystems may continue to define acr values and require them to be sent.

closes #218

→ <<cset 92f9a23e9ab9>>