Thanks for this Jimmy - it's the long-standing major flaw in the 800-63-3 'collections of evidence' - everyone knows about it, but nobody has been able to convince the NIST maintainers that they should fix the problem. I and others been muttering, complaining, pointing out, commenting about invalid requirements like this forever. There is no way to resolve this issue within the current documentary-evidence structure of 800-63. The underlying assumption that "proofing organizations" have total access to data sources and 100% effective physical credential validation machinery is and has been wrong for many years. Similarly, the fact that commercial vendors who are not doing business with US Federal or State governments see 800-63 as somehow valid in non-government scenarios is quite astonishing. At least with the Kantara SAC we have taken efforts to modify/strip out most (hopefully all) of the government dependencies that make no sense in B2B scenarios. As assessors, I would be very interested to hear about your actual experience with actual assessments. Just like the 'components' argument, where I was surprised by your recounting what happens in the field (I should not have been surprised, but I was) - I'd like to hear how companies have worked around the tight restrictions and convinced their assessors too. Just in case I have to change my understanding in this situation as well. andrew. ———————— *Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com On Fri, Jun 28, 2024 at 7:27 AM Jimmy Jung <jimmy.jung@slandala.com> wrote:

Here is a fun bit of nonsense.

I gave NIST’s notional strength of evidence page to a client to help them expand on their approaches to IAL2, thinking that the notional strength of evidence page, which we have adopted; identifies and classifies many additional options for identity evidence. But as we dug in, things got murky. https://pages.nist.gov/800-63-3-Implementation-Resources/63A/resolution/

SP 800-63 and Kantara require that “The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG.(63 4.4.1.3; see also 63A#0200)” This is compared with verification which is only compared to the strongest piece of identity evidence. (63 5.3.1))

And, validating evidence at STRONG requires having “*all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s).”*

Thank god for AAMVA, but out of curiosity, what issuing, authoritative, or even credible source would validate a Permanent Resident Card, Native American Enhanced Tribal Card, “Enhanced ID cards,” U.S. Military ID, Permanent Resident Card or Native American Tribal Photo Identification Cards? Calling them SUPERIOR or STRONG isn’t really meaningful, if they cannot be validated that way.

There are some cool implementations that can read a passport and verify digital signatures, but for PIV, CAC, PIV-I (and TWIC?) you are going to need a card reader, so that mostly leaves out unsupervised. I think validating a digital signature is a fairly strong validation, even if it does not really COMPARE information with an issuing or authoritative source?

Things really seemed odd to me, when we came to the conclusion that you would have to consider a US Navy CAC card a “FAIR” piece of evidence, because the DoD doesn’t validate CAC cards.

For an unsupervised proofing, and working from NIST’s notional strength of evidence page, which TWO items can you compare with information held by an issuing or authoritative source?

US Passport

SUPERIOR

Foreign e-Passport

SUPERIOR

Personal Identity Verification (PIV) card

SUPERIOR

Common Access card (CAC)

SUPERIOR

Personal Identity Verification Interoperable (PIV-I) card

SUPERIOR

Transportation Worker Identification Credential (TWIC)

SUPERIOR

Permanent Resident Card

SUPERIOR

Native American Enhanced Tribal Card

SUPERIOR

REAL ID cards

STRONG+

Enhanced ID cards

STRONG+

U.S. Uniformed Services Privilege and Identification Card (U.S. Military ID)

STRONG+

Permanent Resident Card

STRONG

Native American Tribal Photo Identification Card

STRONG

Driver’s License or ID card (REAL ID non-compliant)

STRONG

Jimmy

_______________________________________________ A Community Group mailing list of KantaraInitiative.org WG-IDAssurance mailing list -- wg-idassurance@kantarainitiative.org To unsubscribe send an email to staff@kantarainitiative.org List archives -- https://mailman.kantarainitiative.org/hyperkitty/list/wg-idassurance@kantara... ______ Group wiki -- https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance

The issue is more about specification of requirements that have a chance of being met by real world implementations - and that are used in the real world. Is a "credible" source better or worse than an "appropriate" or "proportionate" or "suitable" or "trustworthy" source? It's a meaningless qualifier. The core conceptual structure of "collect some documents (or digital documents, or electronic data), confirm that the medium is valid and 'appears' untampered, cross-match some data elements to 'ensure' that the pieces are about the same individual, then compare to the human' is fundamentally flawed as it relates to the degree of confidence that one has the correct (and only) person. It partially reflects a 'closed population' viewpoint - where the total population is known and registered somewhere accessible (like a citizen registry in EU member states) and the "proofing" exercise is to figure out which person in your registry is asking for service. This, conceivably, is the world of government-to-resident service delivery. It all kinda breaks down in 'open population' situations - good luck finding a "credible" source for a tourist with an official looking document from somewhere outside of your database scope. Which is often the world of commercial services. Trying to get to 100% potential population coverage for identification documents is a losing proposition. Do your customers take your service's answers at face value? or do you offer to do 'additional checks' for them that are not in 800-63? The 'additional checks' like specific watch lists, anti-fraud networks, counterfeits lists, whatever - those are the things that ID Proofing and Verification needs - not 'gather a bunch of documents'. From my (limited) understanding - no org needing high confidence in identification would accept pure IAL2 as written - they will always want additional checks or correlations or step ups. Please tell me I'm wrong. andrew. ———————— *Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com On Fri, Jun 28, 2024 at 9:27 AM Scott Jones <scott.jones@clearme.com> wrote:

Andrew / All,

Does the addition of the "Credible Source" in 800-63-4 reduce the burden when validating identity evidence?

The allowance of 1 STRONG / 1 FAIR certainly seems to reduce the *scale* of the problem since there's only 2 pieces to validate.

Scott Jones

Group Product Manager

85 10th Avenue, 9th Floor | New York, NY 10011

*scott.jones@clearme.com <scott.jones@clearme.com>* | www.clearme.com

On Fri, Jun 28, 2024 at 11:35 AM Andrew Hughes <andrewhughes3000@gmail.com> wrote:

...

Thanks for this Jimmy - it's the long-standing major flaw in the 800-63-3 'collections of evidence' - everyone knows about it, but nobody has been able to convince the NIST maintainers that they should fix the problem. I and others been muttering, complaining, pointing out, commenting about invalid requirements like this forever.

There is no way to resolve this issue within the current documentary-evidence structure of 800-63. The underlying assumption that "proofing organizations" have total access to data sources and 100% effective physical credential validation machinery is and has been wrong for many years. Similarly, the fact that commercial vendors who are not doing business with US Federal or State governments see 800-63 as somehow valid in non-government scenarios is quite astonishing. At least with the Kantara SAC we have taken efforts to modify/strip out most (hopefully all) of the government dependencies that make no sense in B2B scenarios.

As assessors, I would be very interested to hear about your actual experience with actual assessments. Just like the 'components' argument, where I was surprised by your recounting what happens in the field (I should not have been surprised, but I was) - I'd like to hear how companies have worked around the tight restrictions and convinced their assessors too. Just in case I have to change my understanding in this situation as well.

andrew.

———————— *Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com

On Fri, Jun 28, 2024 at 7:27 AM Jimmy Jung <jimmy.jung@slandala.com> wrote:

...

Here is a fun bit of nonsense.

I gave NIST’s notional strength of evidence page to a client to help them expand on their approaches to IAL2, thinking that the notional strength of evidence page, which we have adopted; identifies and classifies many additional options for identity evidence. But as we dug in, things got murky. https://pages.nist.gov/800-63-3-Implementation-Resources/63A/resolution/ <https://url.us.m.mimecastprotect.com/s/OMecCERXjLtqZnQMSpTw0x/>

SP 800-63 and Kantara require that “The CSP SHALL validate identity evidence with a process that can achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG.(63 4.4.1.3; see also 63A#0200)” This is compared with verification which is only compared to the strongest piece of identity evidence. (63 5.3.1))

And, validating evidence at STRONG requires having “*all personal details and evidence details confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s).”*

Thank god for AAMVA, but out of curiosity, what issuing, authoritative, or even credible source would validate a Permanent Resident Card, Native American Enhanced Tribal Card, “Enhanced ID cards,” U.S. Military ID, Permanent Resident Card or Native American Tribal Photo Identification Cards? Calling them SUPERIOR or STRONG isn’t really meaningful, if they cannot be validated that way.

There are some cool implementations that can read a passport and verify digital signatures, but for PIV, CAC, PIV-I (and TWIC?) you are going to need a card reader, so that mostly leaves out unsupervised. I think validating a digital signature is a fairly strong validation, even if it does not really COMPARE information with an issuing or authoritative source?

Things really seemed odd to me, when we came to the conclusion that you would have to consider a US Navy CAC card a “FAIR” piece of evidence, because the DoD doesn’t validate CAC cards.

For an unsupervised proofing, and working from NIST’s notional strength of evidence page, which TWO items can you compare with information held by an issuing or authoritative source?

US Passport

SUPERIOR

Foreign e-Passport

SUPERIOR

Personal Identity Verification (PIV) card

SUPERIOR

Common Access card (CAC)

SUPERIOR

Personal Identity Verification Interoperable (PIV-I) card

SUPERIOR

Transportation Worker Identification Credential (TWIC)

SUPERIOR

Permanent Resident Card

SUPERIOR

Native American Enhanced Tribal Card

SUPERIOR

REAL ID cards

STRONG+

Enhanced ID cards

STRONG+

U.S. Uniformed Services Privilege and Identification Card (U.S. Military ID)

STRONG+

Permanent Resident Card

STRONG

Native American Tribal Photo Identification Card

STRONG

Driver’s License or ID card (REAL ID non-compliant)

STRONG

Jimmy

_______________________________________________ A Community Group mailing list of KantaraInitiative.org WG-IDAssurance mailing list -- wg-idassurance@kantarainitiative.org To unsubscribe send an email to staff@kantarainitiative.org List archives -- https://mailman.kantarainitiative.org/hyperkitty/list/wg-idassurance@kantara... <https://url.us.m.mimecastprotect.com/s/9RJ1CBBXWGtnLAgBszW1vN/> ______ Group wiki -- https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance

*Warning*

Email sent from outside of *CLEAR <https://www.clearme.com>*. Please be mindful of clicking on links and opening any attachments that may be included with this email. _______________________________________________ A Community Group mailing list of KantaraInitiative.org WG-IDAssurance mailing list -- wg-idassurance@kantarainitiative.org To unsubscribe send an email to staff@kantarainitiative.org List archives -- https://url.us.m.mimecastprotect.com/s/9RJ1CBBXWGtnLAgBszW1vN ______ Group wiki -- https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance

But actually, I was thinking of throwing a stick of dynamite … =:-o Richard G. WILSHER CEO & Founder, Zygma Inc. www.Zygma.biz +1 714 797 9942 From: Jimmy Jung [mailto:jimmy.jung@slandala.com] Sent: Sunday, June 30, 2024 03:01 To: Andrew Hughes Cc: Amanda Gay; wg-idassurance@kantarainitiative.org Subject: [WG-IDAssurance] The CSP SHALL ensure that MF-CS key authenticators DO NOT facilitate the cloning of the secret key onto multiple devices. (RE: Synch-able authenticators) Perhaps Andrew will appreciate me throwing a completely different log on the fire. We briefly discussed what we should do about NISTs synchable authenticator supplement and concluded that it was at least worth waiting got the next 3-4 draft, to see which way the wind is blowing. That still seems quite reasonable, but I will reiterate that have a few clients that are quite keen to see this leveraged. That being said, I did try to dig onto WebAuthn. I had assumed that we had the ability to prevent the generation of synchable passkeys as they are registered with the CSP, but I’m having a hard time seeing that when I look through the protocol. I see an ability to NOT ACCEPT synched passkeys on the authentication side, but no way to prevent their creation at registration. https://webauthn.guide/#webauthn-api When the user creates their passkey, the server/CSP can ONLY specify if the credential is “Cross-platform” (i.e., removable; e.g.,yubikey) or “platform” (i.e., SW, tied to the device). But you CAN”T specify if it is backup eligible (i.e., synchable). You CAN ONLY reject that authenticator after it has been created. So, to prevent synchable authenticators, we would have to ONLY ALLOW user to create and use Yubikeys and other removeable HW authenticators. I think that cuts out a large swath of the passkey utility, until synchability is allowed. Jimmy AT REGISTRATION, we can specify the authenticator type. “authenticatorSelection” seems to define the constraints. HOWEVER, I am very uncertain if this is granular enough to exclude cloneable authenticators. authenticatorSelection: This optional object helps relying parties make further restrictions on the type of authenticators allowed for registration. In this example we are indicating we want to register a cross-platform authenticator (like a Yubikey) instead of a platform authenticator like Windows Hello or Touch ID. <https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-authenticatorselection> Read the spec. From the specification ( <https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-authenticatorselection> https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-authe...): “authenticatorSelection, of type AuthenticatorSelectionCriteria The Relying Party (the server/CSP) MAY use this OPTIONAL member to specify capabilities and settings that the authenticator MUST or SHOULD satisfy to participate in the create() operation. See § 5.4.4 Authenticator Selection Criteria (dictionary AuthenticatorSelectionCriteria). <https://w3c.github.io/webauthn/#dictdef-authenticatorselectioncriteria> https://w3c.github.io/webauthn/#dictdef-authenticatorselectioncriteria authenticatorAttachment, of type DOMString If this member is present, eligible authenticators are filtered to be only those authenticators attached with the specified authenticator attachment modality (see also § 6.2.1 Authenticator Attachment Modality). If this member is absent, then any attachment modality is acceptable. The value SHOULD be a member of AuthenticatorAttachment but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. We refer to authenticators that are part of the client device as platform authenticators, while those that are reachable via cross-platform transport protocols are referred to as roaming authenticators. … The primary use case for platform authenticators is to register a particular client device as a "trusted device", so the client device itself acts as a something you have authentication factor for future authentication. This gives the user the convenience benefit of not needing a roaming authenticator for future authentication ceremonies, e.g., the user will not have to dig around in their pocket for their key fob or phone. ( <https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality> https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality) Looking instead at NIST’s 800-63B supplement, where they discuss synchable authenticators. <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pd... In Table 2. WebAuthn Level 3 flags, they identify: Backup Eligibility – which Indicates whether the authenticator can be synced to a different device (i.e., whether the key can be stored elsewhere). AND Backup State – which Indicates whether an authenticator HAS been synced to a different device. NIST specifically says that “Federal agencies MAY use this flag if they intend to establish restric�ons on authen�cators that have been synced to other devices. For public facing applica�ons, agencies SHOULD NOT change the acceptance based on this flag due to user experience concerns. For enterprise decisions, this flag MAY be used to support the restric�on of syncable authen�cators for specific applica�ons.” (excuse the pdf to MS cut and paste) I Don’t know where in the protocol these show up (somewhere in the <https://w3c.github.io/webauthn/#authenticator-data> https://w3c.github.io/webauthn/#authenticator-data). But this may only allow us to prohibit their use, not control if they are created. I would note that NIST only discusses this in terms of a multi-factor authenticator, but I assume they are accepting the premise that passkey is multifactor, even if the “thing-you-have” is your laptop (of public library computer?)