I've also implemented login.gov as an identity provider of last resort for a system that requires identity proofing (IAL2). It works great once folks are signed up and verified for a login.gov account, but the identity assurance process always seems to end up requiring a piece of mail sent to new users' homes. The phone/utility verification process never seems to work right, and the postal mail option adds a week's delay (or more) to our user enrollment process. In my and several test users' cases, we've had our phone numbers in our names for literally decades, so it isn't a matter of public records being ambiguous.
We've also had problems getting login.gov to proof new users with national but not state IDs. For example, we have someone with a passport but no driver's license. They should be able to use just the passport for identity proofing since the passport itself requires two or more forms of SUPERIOR/STRONG evidence (per NIST SP 800-63-3), but login.gov must not authenticate the passport with the State Department, meaning it fails 800-63A 4.4.1.2 (evidence collection requirements) rule 1 and must implement rule 2, instead (collect two pieces of STRONG evidence, i.e., national _and_ state IDs both). It's really frustrating because I cannot demand my users go out and get (pay for) state IDs they don't otherwise want or need.
All that said, even though login.gov isn't perfect, I do like it and am very impressed with 18F/TTS's work. They've done a very thorough job with their SAML implementation compared to the ADFSes/Oktas/Pings/etc. of the world.
We've also had problems getting login.gov to proof new users with national but not state IDs. For example, we have someone with a passport but no driver's license. They should be able to use just the passport for identity proofing since the passport itself requires two or more forms of SUPERIOR/STRONG evidence (per NIST SP 800-63-3), but login.gov must not authenticate the passport with the State Department, meaning it fails 800-63A 4.4.1.2 (evidence collection requirements) rule 1 and must implement rule 2, instead (collect two pieces of STRONG evidence, i.e., national _and_ state IDs both). It's really frustrating because I cannot demand my users go out and get (pay for) state IDs they don't otherwise want or need.
All that said, even though login.gov isn't perfect, I do like it and am very impressed with 18F/TTS's work. They've done a very thorough job with their SAML implementation compared to the ADFSes/Oktas/Pings/etc. of the world.