Relying Party plus a PIN

Some relying party websites want to add an additional layer of security beyond the use of an identity provider. This requires finding a good balance of usability/security because the banks have found that those additional layers generally have little significant statistical impact on reducing fraud. The most common approach is for the website to do a regular login, but then require the user to type a ~4 digit PIN (as opposed to a complex password) when their session times out or they are performing a high risk transaction. This approach is very similar to how smartphones like Android work where a user has to login once to the phone when they buy it, but then the phone locks after a few minutes of inactivity and the user needs to type a PIN to unlock it.

When websites using this approach, it works particularly well when combined with an identity-provider because every time the site might ask the user for a PIN, it can first redirect the user to the identity provider to confirm they still have a valid session. If they do, they will get redirected back invisibly to the user, and the site can ask the user for their PIN.

More sophisticated websites will use risk based models to sometimes just redirect the user to the identity provider without asking for a PIN, and other times do both. If the website has a mobile app or mobile web interface, then generally the risk models show it is now necessary to ask for a PIN because smartphones already have the PIN unlocking feature built it.