EKYC & Identity Assurance Working Group
OpenID Connect is used in a number of places for strong identity assurance, i.e. the Relying Party uses the end-user claims provided by an OP to verify the user’s identity in order to fulfil regulatory or legal requirements, such as anti-money laundering, or in the context of fraud Prevention.
As one fundamental challenge, OpenID Connect (and other standards in this field) do neither reveal what trust framework the OP complies with for collection, verification, and maintenance of particular end-user claims nor do they communicate to the Relying Party important metadata about the verification process, such as when the verification took place, what evidence was checked and using what methods.
This information is essential for a Relying Party seeking to use OpenID Connect for strong identity assurance in order to fully document the assurance level and circumstances under which data was obtained for auditing purposes and to map the assurance level of the OP (or generally speaking the claim source) to the expected trust framework and assurance level of the Relying Party. For example, a RP could intend to use data verified and maintained under anti-money laundering law in the context of the local telecommunications law. Whether this is possible might depend on the verification method or evidence employed for a particular user as some methods allowed in the anti-money laundering context might not be allowed in the telecommunications context.
The eKYC & Identity Assurance Working Group at the OpenID Foundation is working towards OpenID Connect extensions for supporting strong identification use cases. The working group started in January 2020 and took over and continues the previous work on OpenID Connect for Identity Assurance (https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html), which started in the AB/Connect Working Group in early 2019.
OpenID Connect introduces the “verified_claims” structure that is used as a container to convey a set of end-user claims along with the related metadata about trust framework, time, evidence, and methods.
The following example shows a user info response containing, beside other claims, verified claims maintained by the OP in accordance with the German Anti-Money Laundering law, indicated by the trust_framework value “de_aml”.
As illustrated by the example, verification data and end-user claims are conveyed in the separate sub-container elements “verification” and “claims”. The example also illustrates that the concept allows to mix verified and other claims in the same assertion while retaining a clear boundary between them.
Verified claims can also be provided through aggregated and distributed claims, making OpenID Connect for Identity Assurance a suitable tool for combining verified claims from different sources while keeping the clear relationship between the end-user claims and the assurance levels and metadata.
OpenID Connect for Identity Assurance recently passed the 2nd Implementers Draft voting and is already implemented in a number of products and services. It has been tested against the requirements from different jurisdictions by the broad membership of the working group from Asia, Europe, and North America.
As the current specification has gotten stable now, the working group is looking into further topics, e.g. identity assurance for legal entities, and intends to work towards conformance testing for OpenID Connect for Identity Assurance.
Anyone interested in the topic of strong identity assurance and wanting to contribute is highly welcome. The working group holds a weekly call on Wednesday at 3 pm UTC. More information can be found at the working group page https://openid.net/wg/ekyc-ida/ .
Torsten Lodderstedt
CTO, yes.com
When Web Browsers Attack – Browsers, Privacy Preservation, and Identity Flows
The world of web browsers is grappling with a deceptively simple mandate: Protect users from third-party tracking. It’s like a motherhood-and-apple-pie statement: having third parties track individual behavior is a significant issue. Legislation around the world agrees that third-party tracking is a Bad Thing.
But what happens when the technology used by advertisers for third-party tracking is the same technology used by enterprise and academic identity federations to support SSO? Suddenly, that simple mandate of “protect against third-party tracking” can potentially disrupt scholarship and business in significant ways. During Identiverse 2020, Vittorio Bertocci presented “Browser Features vs Identity Protocols: An Arms Race?” If you’re not familiar with how third-party tracking works, and how it is indistinguishable (as far as the web browser is concerned) from identity flows, this 30-minute session is something you need to view.
The good news is that even the browser vendors are still in the early stages of figuring out exactly what they want to do. That allows the broader IAM community to engage in the conversation and ensure that all the major use cases are considered. Discussion on this topic has, at least in part, moved into the W3C’s Web Incubator Community Group through Google’s webID project (https://github.com/WICG/WebID). While the webID developers have, to date, focused solely on the consumer space, issues have been raised to highlight enterprise SSO and academic federation requirements. The good news is, now that this discussion is happening in a public forum, more people can get involved. The bad news is that WICG attracts web API developers; additional expertise will almost certainly be needed in the privacy space and standards development.
The browser vendors are expected to be responsive to the issue of third-party tracking. Given they are still very early in the game of figuring out exactly what they want to do means now is the time for interested parties to get involved and be a part of figuring out a solution that will work for more than just one use case. IAM practitioners, particularly those that support their enterprise SSO environment or who are engaged in supporting academic research and scholarship, should get involved now to help build a robust and implementable solution for all.
Heather Flanagan
Translator of Geek to Human
Spherical Cow Consulting, LLC
News from the Amsterdam Digital Identity Meetup
During the spring and summer the Amsterdam Digital Identity meetup has been running a series of talks around modern authentication and how the different authentication options relate to each other.
We started in January with Multi Factor Authentication where Brian Kloof shared his experience of rolling out Azure AD MFA at a global retailer. In March we learned more about Windows Hello for Business where Pim Jacobs talked about how you implement WHFB in enterprise environments. Finally we got a run through of the FIDO2 standard and how to implement Yubikey in an Azure AD centric enterprise from Per Erngard.
The main conclusion from these talks is that each technology is one piece of the puzzle of minimizing the usage of passwords within an enterprise. MFA will add an additional layer of security on top of password. The main challenge with MFA is the roll out, especially in Corona times as the usual approach of requiring enrollment on corporate premises or via VPN is a lot harder to implement when the majority of the staff is working from home.
Some of our members have chosen to soften the enrollment requirements to get staff onboarded despite the downside that you lose the strong onboarding. Many enterprises are taking advantage of the integration with self service password reset functions that more and more MFA vendors are offering to get an improved user experience and lower help desk password reset call volumes.
Windows Hello For Business is getting increasingly popular and the consensus from our members is that it is a very good option for staff that are provided with company managed Windows 10 laptops that have Windows Hello compatible cameras or fingerprint readers. Some of our members have been trying to roll this out using PIN codes, but that has not been successful as the user experience improvement simply is not big enough.
FIDO2 offers an interesting way of providing very strong authentication for users who do not have personal laptops, but share kiosk style machines. This approach is especially interesting for retailers, hospitality, and healthcare companies that have a lot of staff who are not assigned a personal laptop and who need to be able to quickly log in and log out. If you have an Azure Active Directory centric environment the FIDO2 integration offers an attractive way to increase the authentication strength for key identities and applications.
In the fall we are planning talks on identity analytics in cooperation with Forgerock as well as external identities in AAD with Microsoft. We are also hoping to be able to get back to physical meetings but the online meetings have been very well attended and have facilitated some very good discussion. If you are interested and want to learn more, visit https://www.meetup.com/Amsterdam-Digital-Identity-Meetup-Group/ and sign up.
Martin Sandren
Domain Architect IAM at Ahold Delhaize
