Add level of assurance to scope

[Tom Jones]

The current sid inherently has no level of assurance. It can eve be ephemeral. Most financial institutions operate under "know you customer" regulations. I propose separate level, however there might be better ways to get the same result. Sooo... Level 2 - there is some means for the user to assure that they control access to the account. Level 3 - the user's identity has been proofed (eg KYC) and level two met as well. Level 4 - hardware protection of user access is required (this may not be part of OP, but client)

[Ralph Bragg]

Open Banking was evaluation the vectors of trust spec with a view to making in part of the specification. As it wasn't standardized enough at the time of the OB publication it wasn't included and instead we have ended up with SCA or non SCA (SCA vs CA) as "loa" values. I'd like to see these replaced with a vectors of trust style response that describes everything that Tom mentions.

1. KYC level.
2. Confidnece in ownerhip of credential.
3. Number and type of credentials used

[Michael Schwartz]

OpenID Connect defines acr and amr. The client can request acr either by using the acr_values request parameter, or the default_acr_values client registration metadata. The acr claim is included in the signed id_token. This is the standard claim that was defined t communicate the LOA of a transaction. Although suggested values are provided, the Connect Core spec also says

Parties using this claim will need to agree 
upon the meanings of the values used, 
which may be context-specific. The acr 
value is a case sensitive string.

ACR values are something that can be defined by a company or ecosystem. For example, it would be appropriate for UK Open Banking to define how it uses acr values. And of course, different countries have different ways they might define acr, and they can define their own values.

amr is tougher to use, IMHO, because the client has no way to signal to the OP which amr is requested or preferred. It can be sent as additional information from the OP, in the id_token.

The OP may have knowledge of the identity proofing behind an identity it holds. But it seems implicit that the acr may or may not convey information about identity proofing. The OP may just want to say something like "this client requested and was successful at FIDO U2F authentication". Packing the identity proofing process into the acr also is possible, but you may be able to achieve more granularity by using another user claim.

[Tom Jones]

Just to remind everyone - this is about the request (which i suggested be part of the scope) - which may or may not map directly to the claim provided.

that said - adding detail to FAPI about reporting assurance sounds like a good idea to me as well.

[Nat Sakimura]

@michael_schwartz_ is right. We should be able to leverage acr. It is an IANA registry-based parameter. Whatever the levels etc. you come up with, you can create an entry in the registry and use it.

[Tom Jones]

i guess i need to understand how a client can request a specific level of assurance. Is there any documentation (other than the spec)?

[Tom Jones]

Here is a fuller statement of the problem. The most common open implementation of OpenID Connect, IdentityServer4, and others like the social ids, persist "user consent grants" (ie the stuff shown to the user in the consent page) by the pair (sid, client_id) in the OP and the consent is granted to the user approved subset of the scopes requested by the client - as that is the only required field in the request that relates to what the client wants. So the persisted grant information is just those scopes the user accepted. It is my contention that the assurance level of the authentication must be a part of the consent request, and so must be a part of the scope, unless other fields get included in the "required" list so that the social ids will implement them.

Also the Kantara Consent Receipt only allows a single level of data category. I had hoped to be able to use the scope values in that category field. If there are mixed scope and claims values, i will need some other identification schema for it.

[Nat Sakimura]

It is an important topic so I have opened the ticket. However, since it is a big topic that we cannot come to a closure in two or so weeks, it will be dealt in the version after the coming implementer's draft.

[Nat Sakimura]

This probably belongs to a guidance document.

[Nat Sakimura]

Perhaps we should close this without any action. To be closed in two weeks if nothing happens.

[Nat Sakimura]

Forgot to close.