Jimmy - do you think the conceptual mismatch stems from a) the presumption that 63B makes the CSP role a 'federated authentication' role (meaning the assertion that authentication was successful is transmitted from the CSP to the RP) - versus a 'direct authentication' role (meaning authentication happens at the RP) - or maybe the significant point is that the authenticator is generated by the CSP, the RP, or the device?, b) passkeys are a 'local' authenticator (not federated and not direct), c) 63B has no authenticator type that is 'local' - and therefore we have a categorization mismatch problem. Boiling down to: the 63B concept is for an 'issuing authority' kind of CSP that is able to force configuration policy onto authenticators. Or, more likely, I'm overthinking it - and this is a simple case of 'bring your own authenticator' but the authenticator in question has some interesting properties and limitations? ———————— *Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com On Tue, Aug 6, 2024 at 6:04 AM Jimmy Jung <jimmy.jung@slandala.com> wrote:
Dear IAWG members,
I know we will meet this week to learn more about FIDO and passkeys and consider how to address the 63B supplement in our criteria. We have discussed reviewing the next 63-4 draft as part of our thinking, but the NIST 63-4 draft missed the rumored July release. We can be certain that NIST released the supplement recognizing the market and in an attempt to be agile. I think it behooves us to attempt to be similarly responsive. And, among almost all the organizations I am working with passkeys are desired, if not imperative. I believe we need to take two steps:
- Quickly roll the supplement into the 63-3 criteria. No doubt we will have better perspective if we have the 63-4 draft, but the supplement will still be the 63-3 criteria and if “classic” is any example, it will stay in play for a while. - I also believe FIDO got it wrong, that not allowing a relying party to prevent cloneable keys; to control their own security, is an imprudent selection of “easy” over secure. Kantara, as a digital identity collaborative should formally take a position against this implementation. I don’t mind cloning, but I do mind not allowing a site to disallow cloning as part of THEIR policy (I mean, come on; initially it violated NIST policy) – of course this is all predicated on my understanding the FIDO implementation; something I hope to nail down Thursday. (In looking at this more, I’m getting a sense of the difficulty of this, but I am still convinced it is the right thing to do)
Based on that sense of urgency, I took a first pass at rolling in the supplement (attached). It is fairly straight forward but asks a few questions. One over-arching question; the supplement makes reference to “properly configured syncable authenticators,” and it seems to imply that FIDO/WebAuth is OK; but I have assumed that the actual SHALL statements they gave us ARE the “proper configuration” they are looking for.
For those of you who saw an earlier draft of the criteria, they have been tweaked, based on some suggestions from Richard Wilshire. In that time, I also came up with a few other questions that will no doubt take us down some rabbit holes.
The NIST supplement ONLY addresses Multifactor Cryptographic Software MF-CS Authenticators, not Single-Factor Cryptographic Software Authenticators; and we can assume that NIST has accepted the argument that passkeys are multifactor. But they are only multifactor to the extent that you can consider the device (e.g., workstation or laptop) “something you have.” I’m having to rewire some paradigms to think of my laptop as an authentication token; but if NIST is good with it, I guess I can manage. But if passkeys are Multifactor Cryptographic Software Authenticators then “syncability” is not the only obstacle they have to deal with. The rest of the 63B MF-CS criteria includes rules for the activation data and biometrics (63B 5.1.8 and Kantara criteria 63B#1250 - 63B#1330).
Multifactor Cryptographic Software Authenticators require either a randomly generated 6 digit OR an 8 character activation secret to activate (see below). Can passkeys do either of these? The CSP/relying party has no way to generate a secret for the user and no control over the length of the user generated secret. As best I can tell, I can lower my passkey to four digits and the CSP has no way to know or enforce the length of my passkey activation PIN . Also, the multifactor criteria requires the CSP to zeroize the unencrypted activation secret or biometric sample after authentication AND enforce biometric criteria – and the CSP has no control over that; although maybe by requiring FIDO, that is being met. In general, 63B and our criteria assign a number of items to the CSP, that in passkeys are managed locally. Some of them are perhaps inherited from the FIDO implementation, but I’m cautious about the CSPs ability to control the activation secrets, the rate-limiting, biometric Failed Match Rates or any of the biometric implementation.
- 63B#1290 - The CSP SHALL ensure that memorized secrets used by the authenticator for activation are a randomly-chosen numeric value at least 6 decimal digits in length *or other memorized secret meeting the requirements of the applicable criteria 63B#0410 - '0460.* - 63B#0410 - *The CSP SHALL require memorized secrets chosen by the Subject to be at least 8 characters in length.* - 63B#0420 - The CSP SHALL require memorized secrets generated by itself or a Verifier to be at least 6 characters in length and randomly-generated. - 63B#0430 - If the CSP [or Verifier] determines that a chosen memorized secret appears on a list of compromised values it SHALL require the Subject to choose a different memorized secret. - 63B#1300 - The CSP SHALL enforce a rate-limiting mechanism iaw 63B#1450 & '1460 (without qualification regarding the degree of entropy which the memorized secret exhibits). - *63B#1310 - If a biometric factor is used in an authentication the CSP SHALL ensure that all criteria 63B#1470 - '1550 are fulfilled.* - *63B#1320 - The CSP SHALL zeroize the unencrypted secret key and the activation secret or biometric sample (including any associated biometric data) immediately after an authentication transaction has taken place.*
To some extent I’m wondering if passkeys work under 800-63, even with the NIST supplement.
Jimmy
PS – There are 4 requirements for a Single-Factor Cryptographic Software Authenticator. Those same 4 requirements also apply to Multifactor-Factor Cryptographic Software Authenticators, plus another 6 all relating to the second factor (e.g., biometrics, activation secret). Am I allowed to declare my MF-CS a SF-CS and just ignore those 6 requirements? 😊
Jimmy Jung
*www.Slandala.com <http://www.slandala.com/>*
703 851 6813
Jimmy
*From:* Amanda Gay <amanda@kantarainitiative.org> *Sent:* Tuesday, August 6, 2024 7:30 AM *To:* wg-idassurance@kantarainitiative.org *Cc:* tim.cappalli@okta.com; dean.saxe@beyondidentity.com; alexei.czeskis@id.me; tanel@id.me *Subject:* [WG-IDAssurance] Agenda and Invitation - IAWG - August 08, 2025
Dear IAWG Members:
Please join us this Thursday, at 12 Noon ET for the next IAWG meeting.
The proposed agenda and Zoom details are below. Please also keep an eye out for an email from Jimmy containing a first attempt at rolling the supplement into Kantara criteria!
*Date and Time*
· *Date: Thursday, 2024-08-08*
· *Time: 9:00 PT | 12:00 ET (**time zone calculator* <https://www.timeanddate.com/worldclock/converter.html>*)*
o Please join the meeting from your computer, tablet or smartphone: https://zoom.us/j/93167965850?pwd=dldoT0hYK1k4MkVGYkQ3TkNqdG1Idz09
o Meeting ID: 931 6796 5850
o Passcode: 884696
o You can also dial in using your phone. Find your local number: https://zoom.us/u/aeg9vt8LSr <https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2FabUx61ivsc&sa=D&ust=1633443687084000&usg=AOvVaw3ehbrEjQRyzH1hFSxphQeQ>
o Need to add IAWG meetings to your calendar? Do so here! <https://kantara.atlassian.net/wiki/spaces/IAWG/overview>
*DRAFT 08.08.2024*
1. *Administration:*
o Roll call, determination of quorum.
o Minutes approval
§ Jimmy moves for unanimous, seconded by Hughes. Motion passes.
§ 2024.07.25 DRAFT Minutes <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/569507845/2024-07-25+IAWG+Meeting+Notes+DRAFT>
o Kantara Updates
o Assurance Updates
2. *IAWG Actions/Reminders/Updates:*
- Proposed Meeting Cadence for June/Extended Summer*
- August 8 (Passkey Presentations), August 22 - **If rev.4 is released, this cadence will be updated *
3. *ISO 17065 Discussion Items*
4. *Group Discussion: *
- Passkey Presentations
- Tim Capalli, Okta - Dean Saxe, Beyond Identity - Alexei Czeskis, ID.me
5. *Any Other Business*
--
*Amanda Gay | Administrative Coordinator*
*Twitter:* @KantaraNews
*LinkedIn:* @KantaraInitiative _______________________________________________ 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
