How to represent pending verification

[Mark Haine]

In some cases an identity assurance process can take considerable time due to human elements being needed to complete the full identity assurance. These are often implemented in a back end workflow.

It is also possible that for a particular implementation some end users are pre-verified when a relying party redirects them to a provider and others are not pre-verified. The Relying party has no way to determine whether the end user is pre-verified.

How can an eKYC & IDA flow provide a deterministic service to a relying party if there is a need for a back end process to run that can not be relied upon to complete within sensibe time bounds for an OpenID flow?

[Julian White]

What do you mean by pre-verified?

[Mark Haine]

@Jules I mean that a user was verified some time in the past. Not in association with the request from the relying party

[Dima Postnikov]

This is similar to a use case that we are trying to solve where additional authorisations might be required and have to happen outside of active redirect flow (joint accounts, multiparty approvals for organisations and etc).

Grant management API is trying to surface this “pending status“ to the client and allows it to be queried later:

“When another user's authorisation is required and this occurs after the original authorisation was granted by the user, the client can query the status of consent at any point after the authorization to determine if full user consent has been obtained.”

CIBA is also solving for decoupled authorisation, where client can get notified when the authorisation is ready, so the tokens can be picked up.

[Julian White]

I was thinking along the same lines. Could the OP return an authorisation token in the response basically saying I don’t have what you want right now, I’ll send you something later Then use CIBA to send the details when its ready?

‌

This leads on from a conversation on the last call where we discussed that an OP should only return what an RP asked for, e.g. if they asked for “high” from an eidas TF and the OP doesn’t have “high” then it shouldn’t return a valid result. However this isn’t really what happens in practice and not very helpful because it doesn’t tell the RP what really happened, they can’t tell the difference between a user that is at substantial but needs to go through an uplift process that takes time and users that have failed i.e. the user’s claim to the identity is not legitimate. They also often want “high” but will accept either “substantial” and uplift it themselves, and/or they may take a “they are at substantial and I’m in the process of uplifting them but it takes time” response. This can be because at the high assurance levels it might involve a manual process and the OP can’t do that uplift in real time.

Maybe a way to fix that is for the RP to ask for multiple assurance levels and the OP tries to return the highest one they have that matches what the RP asked for. Also if the RP is allowed to ask for more than one assurance level then they could also ask for “pending”, which means “give me a successful response when you don’t have the highest assurance level I’ve asked for and are in the process of uplifting it”. For example:

• RP request saysidentity_assurance_level:high; OP only returns users at high
• RP request says identity_assurance_level:high & identity_assurance_level:substantial; OP returns users at high where they have it, but also those users that are only at substantial
• RP request says identity_assurance_level:high & identity_assurance_level:pending; OP returns users at high where they have it, but also those users that have not reached highbecause they are still in the process of having their ID confirmed to that level
• RP request says identity_assurance_level:high & identity_assurance_level:substantial & identity_assurance_level:pending; OP returns users at high where they have it, those users that are at substantial and those users that have not reached substantialbecause they are still in the process of having their ID confirmed to that level

The pending state is basically an instruction to the OP to get the user the lowest assurance level that the RP will accept and the OP is acknowledging that is what they are doing.

‌

‌

[Mark Haine]

It feels to me that the pending state is not in itself an identity assurance level and that we might be overloading that claim.

I wonder if there is something in the direction of the abort/omit PR that Daniel is working on. Perhaps an additional “case key” like “if_pending”?

NOTE - I haven’t digested the Grant Management stuff properly yet

[Sascha Preibisch]

Here in Vancouver I can check my tax status online. I can view my account and update profile information. However, when signing up for this service I have to prove who I am by answering personal questions that have to match a tax return slip that I posted earlier. Answering these questions is not sufficient though for accessing all possible features.

The tax system will send out an ‘authorization code’ via mail (as in post office mail) which I have to provide online after receiving it. During that ‘pending verification' period I can simply only access like 80% of all available features.

With that in mind I think the ‘pending’ state does not need to be shared with client applications. If data is not available, it is not available.

If the client relies on a verification process that takes longer than a suitable request/ response time frame notification should be used. The client could also receive an URL which it can poll (with rate limits.

Not sure if this is too confusing but those are my thoughts.

[Peter Bainbridge-Clayton]

Unstructured thoughts on this:

This might not just apply to human back end processes of course - there are still electronic processes that have physical time limitations that might take longer than an arbitrary timeout, but needn’t actually prevent the user flow from continuing.

One grids example that springs to mind is where claims are verified via data, but a document which is the legal ‘proof’ is assumed to be be able to be delivered at that point in time. The plan is then to provide a URL for out of band polling. The user facing process can continue, and the RP back end processing can continue up to a point, or certain parts can continue in parallel.

Any mechanism should provide for polling and pushing and (possibly) pinging modes. CIBA looks llike it would fit the bill, but I wonder if it is complex for this scenario - that’s just from a high level skim of the documentation with it though.

Polling is relatively simple - maybe a ‘pending’ block within the ‘verified_claims’ structure? That could be an array mapping the claim to a URI of some form. But would likely end up OOB.
Ping and Push are slightly complex as they would require the RP to specify some form of URI with the request, or have it configured in the JWKS maybe..?

[Naohiro Fujie]

I heard that some of implementation in Japanese KYC service providers provides webhook call for pending verification.

If a RP requests identity proofing to the KYC service provider and the KYC service provider does not have pre-verified claims, the service returns pending status to the RP. After the KYC service provider has complete identity proofing, the service POST the result to the pre-defined webhook endpoint.

Maybe CIBA will provide similar mechanism but I assume that this scenario is quite complex and there are a lot of consideration on implementing RPs as well as implementing OPs. So I guess minimum requirement on OIDC4IDA is define value to express for pending verification is required which is returned from OP to RP and if a RP received the value it is depend on RP implementation such as retrying to get claim after a while, etc.

[Julian White]

Perhaps then it needs some sort of status value to tell the RP to say that the process hasn’t finished.

To the point Sascha made about polling, that would work as long as the RP knew the process hadn’t finished and where to poll, and there might be multiple ways the pending state might be closed down and the OP needs to pass back the right information so that the RP knows what is going to happen next. I think there are at least these options:

1. Random retry by the RP: the OP sends a pending status back to the RP, the RP just gets the user to login to the OP at times in future to get the current status, there is no guarantee that anything will have changed.
2. RP polls the OP: RP calls the OP on a regular basis to see if there are any changes. The OP would need to return a URI or some identifier, and potentially an authorisation token of some sort (to stop other people polling random URIs) for the RP to be able do the polling.
3. OP updates the RP later: OP posts the outcome of the verification journey to the RP at a later date. The RP should send a URI/identifier, and maybe a token, in the request to the OP so that the OP can post it back. (Would CIBA be relevant here?).

‌

[Naohiro Fujie]

Pending verification is also required for legal entity verification. for example, in some case Japanese legal entity registry does not have enough data to verify legal entity beneficial owner. This is due to historical matter and Japanese government is making effort to gather BO in the registry but unfortunately it will take a long period.

I think the pending verification will be one of the solutions to achieve this problem if OPs are able to notify a request for additional information to be verified to the legal entity as well as notifying to the RP.

[Sascha Preibisch]

After reading through the comments I think a solution needs to support the ‘pending’ state. there seem to be good reasons for that.

In order to notify interested RPs a notification feature is desired. As a service provider I would want to collect callback_uris that are notified once the state changed from ‘pending’ to ‘completed’ or ‘verified’ or whatever it may be.

Having the list of callback_uris is also easy to handle for RPs. They simply wait for the response and do not need to poll an endpoint, handle rate limit issues or other errors.

[Peter Bainbridge-Clayton]

One issue with callbacks (although it is the technologically preferred way) is the RP security model. It’s quite common for banks, for example, to not permit any inbound connections and who are therefore forced to poll in one form or another.

[Mark Haine]

couple of things to consider then one might be to take inspiration from CIBA… https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.5

Other is to look at using the work of SSE as they have a pre-defined event in CAEP that fits quite well… https://openid.net/specs/openid-caep-specification-1_0.html#rfc.section.3.2

‌

[Nick Mothershaw]

We have this requirement in the TISA Project. Pending happens when:

When a user is unable to complete the proofing process within a single session the response from the IdP will be “pending”. This occurs for two main reasons:

1. The user chooses to complete the proofing process later, for example when they can access an ID document they need. 
2. The IdP cannot complete the process in a single transaction, for example where an ID Document Scan and Selfie are queued for manual review.

A number of the IdPs in the PILOT have a pending state. 

Once the user has completed the proofing process with the IdP, and they have been successfully ID proofed, a method for the IdP to re-commence the transaction is required.

The suggested approach is that the IdP calls an RP re-start point link with the transaction_id that originated at the RP. The RP can then retrieve the transaction and ask the user is they wish to continue to open the product they originally selected.

This is clearly more implementation and integration work for the RP, but will avoid losing users who go into pending state.

For the pilot it has been agreed that RPs will not implement a re-start point. However, IdPs will indicate when an ID Request goes into pending state by returning an IdP ID Token with a ‘result’ code of ‘pending’. This will allow the scheme and RPs to track how many users go into this state.  

The ‘result’ code is one of several we are putting in a idconnect_extensions object. Other codes required are:

‘assured’. The requested Level of Assurance: “idconnect_kyc_assured” was achieved

‘proofing-fail’. The IdP was unable to achieve the level of assurance. Insufficient evidence was collected to result in a “partial” result status.

‘authentication-fail’. The user has an ID with the IdP but was unable to assert their authenticators

‘fraud_refer’. The IdP has referred the request to its fraud team for investigation. 

Pending IdP or the user has proactively suspended the process whilst until further ID proofing takes place. 

‘partial’. The requested Level of Assurance: “idconnect_kyc_partial” was achieved. Any evidence collected and verified as part of the process is returned to the RP so the RP can complete the process.

---

[Mark Haine]

There was a good discussion on the WG call of 06-04-2022 about how this might be implemented and based on that there was a feeling within the group that the CAEP based approach might be better suited.

One possible implementation would be simply to implement OpenID for IDA and CAEP together and do nothing additional within the OpeID for IDA specification.

One area that seems worthy of deeper investigation is how best to indicate to the PR that there is a process running asynchronously that could result in updated claims becoming available at some point later (via userinfo perhaps?)

CAEP - https://openid.net/specs/openid-caep-specification-1_0.html

Shared Signals and Events Framework - https://openid.net/specs/openid-sse-framework-1_0.html

‌

‌

[Arun Kiezpadathil]

Pending verification = eKYC process underway and has not yet met the set requirements? OR is the desire to allow firms to transact with the customer whilst we await completion of verification?

If latter, it’s then up to each firm to decide (based on their risk appetite + customer risk rating + product risk rating) if the ‘pending verification’ inhibits their ability to demonstrate that they meet the regulatory mandate of ‘know your customer’.

Used to be the case in years past that you could open an account, apply a post credits only (PCO) status and proceed but that is no longer defendable.

[Mark Haine]

My understanding is the former - as you say “Pending verification = eKYC process underway and has not yet met the set requirements“

[Arun Kiezpadathil]

Thanks Mark. In that case the best way to represent the above would be to display an indicator to highlight what percentage of the profile requirements are complete and then have the ability to drill down and show what is outstanding. This will then allow the firms consuming the profile to decide what is acceptable to them based on their own risk appetite and internal controls that helps them mitigate the risk.

I do recommend that we set a minimum threshold even to qualify to be listed as pending i.e., if I start the process, add my name and then stop, displaying my name as ‘pending verification’ would add little value.