800-63 is confusing and contradictory in places, and uses Federal Government terminology throughout. You should be unable to assess a non-government company using 800-63 directly, and if you did, you'd be very confused about roles and responsibilities since some of them point at Federal government org structures which obviously do not exist in the commercial org. So Kantara has adjusted the language appropriately, stripped out excess verbiage, and defined a program that can consume evaluations using the SoCA structure (which is a Kantar thing, not an 800-63 thing) But other than those differences, they are identical :-) ———————— *Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com On Wed, Oct 16, 2024 at 3:40 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
Actually, in many cases, it specifically says federal only applies to internal; government to citizen is not included. (don’t think I’ll have time to sort out the case here)
I’m going with blasphemy. If we can defer to 63B, why have a SAC/SoCA at all?
*From:* Andrew Hughes <andrewhughes3000@gmail.com> *Sent:* Wednesday, October 16, 2024 6:36 PM *To:* Jimmy Jung <jimmy.jung@slandala.com> *Cc:* Richard G. WILSHER (@Zygma Inc.) <RGW@zygma.biz>; wg-idassurance@kantarainitiative.org *Subject:* [Junk]Re: [Junk]Re: [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
OK - so what I hear in that response is that except for unusual cases such as possibly login.gov (being the only Federal agency-operated CSP that I know of that got their trust mark) those criteria marked "federal agency" apply to them. For commercial CSPs, the assessors put all of those criteria out of scope and thus do no assessment of them.
Would it be blasphemy to suggest that in the syncable authenticators supplement for 63-3 we directly defer to 800-63B for the Federal-only requirements? Instead of trying to rewrite and interpret them? Either way is fine by me.
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 3:30 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
Federal system almost always (and where I’ve been involved, always) have a privacy analysis (usually called for by FISMA) – larger CSPs are going to have privacy analysis as well.
But is your question generically about an agency that uses a CSP and how federal only criteria is handled? To my thinking, if the CSP gets certified, then the Federal criteria does not apply. If the federal agency gets certified (and yes, I’ve done one or two); then THEY would have to pony up the privacy stuff, perhaps their own shop does the work, perhaps they procure it from the CSP. If a federal agency contracts with a CSP, but does not get certified, there are no assessors to ask such questions (which is not to say they don’t get asked, I just don’t ask).
*From:* Andrew Hughes <andrewhughes3000@gmail.com> *Sent:* Wednesday, October 16, 2024 6:13 PM *To:* Jimmy Jung <jimmy.jung@slandala.com> *Cc:* Richard G. WILSHER (@Zygma Inc.) <RGW@zygma.biz>; wg-idassurance@kantarainitiative.org *Subject:* Re: [Junk]Re: [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
Question for the assessors then:
How do you normally assess 63B#0400 ?
It's only for US Federal Agencies and says:
Federal Agencies SHALL:
in consultation with the Agency's Senior Agency Official for Privacy, conduct an analysis determining whether the requirements of the Privacy Act are triggered, according to the agency's CSP and/or RP role(s).
Do you assess situations where an external CSP and Federal Agency use some kind of blended service - so that you have to assess what the Federal Agency has in place?
Or are all of your assessment contracts solely with external CSPs?
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 2:56 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
Not questioning your love for the passkeys; but struggling to see how the enterprise management gets into the mix. Columns E & H make a CSP vs Fed distinction, is there a subtlety I missed in that regard?
jimmy
*From:* Andrew Hughes <andrewhughes3000@gmail.com> *Sent:* Wednesday, October 16, 2024 5:51 PM *To:* Jimmy Jung <jimmy.jung@slandala.com> *Cc:* Richard G. WILSHER (@Zygma Inc.) <RGW@zygma.biz>; wg-idassurance@kantarainitiative.org *Subject:* [Junk]Re: [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
I'm repeating myself here as well - where did anyone get the idea that I do not support getting passkeys into the mix? That's an absurd position.
Yes - i'm pretty sure I accept the approach of marking the unenforceable stuff as 'not applicable' with the stated reason.
My thing is, I think that the discriminator in the list of requirements is "the requirements that apply to Feds" and "the requirements that apply to consumer-provided".
Noting that the former partly overlaps with the latter.
What I'm unsure about is that the fact that there are two sets of (overlapping) requirements is obvious - and whether it matters. My gut feeling is that the language we use in our criteria would be simpler to write if we have a distinction between "applies to all" and "applies to Feds"
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 2:45 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
I view it this way – and no doubt I am repeating myself.
Our choice is to decide to support passkeys, as NIST intended. To do so will require us to address the items that we feel, and they acknowledge, were not addressed by the criteria. This is accomplished by allowing the unenforceable criteria to be marked “not applicable”.
The other choice is to not allow passkeys, which seems to only spite our face.
There are requirements which ONLY apply to Feds and they are addressed as such in the supplement and the draft criteria; but I don’t think the distinction is BYOD as much as it is assurance ( I may be wrong, they talk about the fabric, as I recall). Certainly, an organization who issues authenticators could also apply enterprise controls, but the supplement does not (and I don’t think we should) have criteria that says “if you have enterprise control, you must …” It feels like we might get some perverse incentives.
*From:* Andrew Hughes <andrewhughes3000@gmail.com> *Sent:* Wednesday, October 16, 2024 5:14 PM *To:* Jimmy Jung <jimmy.jung@slandala.com> *Cc:* Richard G. WILSHER (@Zygma Inc.) <RGW@zygma.biz>; wg-idassurance@kantarainitiative.org *Subject:* Re: [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
I view the overlay pattern differently.
The 800-63 requirements that apply to ALL syncable passkeys apply to user-supplied, user-controlled syncable passkeys and also "Federal" syncable passkeys.
The requirements that are identified as applicable to only Federal situations only apply to Federal situations. BUT this second set of requirements (I think, but am not sure - correct me) could be controlled using enterprise endpoint management software - because the device is not BYOD - it is owned by the Feds.
So the list of requirements for Federal-controlled syncable passkeys is longer than the list for user-controlled/supplied syncable passkeys. And all of these requirements could be put into the administrative control of the Federal Agency.
That was not super-obvious to me - but that might just be the way I was looking at it.
Don't ask me how an external CSP can work with Federal endpoint management software - my brain hurts - because the CSP might have to receive assurances from the Agency that they are applying the controls thus absolving the CSP from observing settings that they are unable to observe. Noting that for the consumer-supplied stuff this is exactly why some of those controls about settings are outside of the knowledge of the CSP - because the controlling party is not the CSP nor is it the Agency - it is private entities.
This is what gets me tied up in knots about most of 800-63 - the document blends the boundaries of administrative control boundaries between CSP/Agency (see also all the risk management bits).
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 2:04 PM Jimmy Jung <jimmy.jung@slandala.com> wrote:
In the several previous meetings, we had reached concurrence on the idea that NIST, while wanting to make passkeys AAL2, had not properly addressed those control not observable from the CSP and outside of the CSPs control. This effort has, since the beginning, been about adding in the “new” controls from the supplement and also trying to elegantly steer around those control not observable from the CSP and outside of the CSPs control. What the wording should indicate is that for syncable authenticators these criteria maybe marked as “Not Applicable.” We have been struggling with how to properly explain that (in the criteria or guidance) and if it is unclear, then we need to work on it again.
However, the baseline assumption is that these are NOT under the control of the CSP or Federal Agency; these are bring-your-own. User-provided syncable passkey on a user-provided device are the specific target of the supplement; I don’t think end-point management has a play here.
One larger question that must be resolved is the scope of this. NIST’s tone focuses on FIDO passkeys; but we have all heard them clearly say there are other authenticators out there that create the same outside of the CSPs control problem (e.g., software certs or OTP apps on cell phones). Their language ties this to syncable authenticators, which we all take to mean FIDO passkeys; but should we SAY FIDO passkeys or use their language “syncable authenticators” or look at all authenticators outside CSP control; all BYOD devices?
Jimmy
*From:* Andrew Hughes <andrewhughes3000@gmail.com> *Sent:* Wednesday, October 16, 2024 4:53 PM *To:* Richard G. WILSHER (@Zygma Inc.) <RGW@zygma.biz> *Cc:* wg-idassurance@kantarainitiative.org *Subject:* [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
And I'm still trying to parse out the 63B#1980 criteria and below that are directly on the supplement contents.
Am I missing it? where's the text that describes how endpoint management tools can be used to enforce settings on devices that are under the control of the CSP or Federal Agency? That's essential stuff - because if the syncable authenticator config and the device on which the syncable authenticator is installed are under the control of the CSP or Agency, then I think (most/all) of the criteria could theoretically be met and the controls on those aspects could be enforced.
The big gap is a user-provided syncable passkey on a user-provided device. That's the category where the CSP has no information about configuration and also cannot force configuration.
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 1:40 PM Andrew Hughes <andrewhughes3000@gmail.com> wrote:
I don't understand the wording of e.g. 63B#1290-1320 - specifically these criteria refer to things like "enforce a rate-limiting mechanism" for MF cryptographic software authenticators. Where the proposed criterion talks about "where authenticators that allow the cloning of the secret key..."
But the whole problem with syncable authenticators is that that kind of control is not observable from the CSP viewpoint and is outside of the control of the CSP.
It has nothing to do with syncable passkeys - it has to do with authenticator settings that the CSP has no info/control over.
————————
*Andrew Hughes *CISM m +1 250.888.9474 AndrewHughes3000@gmail.com
On Wed, Oct 16, 2024 at 12:20 PM Richard G. WILSHER (@Zygma Inc.) < RGW@zygma.biz> wrote:
Jimmy and I got a little out of step (my tardiness!) and I didn’t get some further thoughts to him in time, so I attach a possible further iteration of these criteria. I think we’re homing-in on a consensus position.
One thing I want to stress independently is the idea of having a ‘FIDO Passkey Profile’. We’ve talked about profiles in the past and defined a basic structure and rules for them. Both Jimmy and I are concerned about the “FIDO-ness” of these proposed changes and the fact that we’re really employing euphemisms for passkeys and abrading the notion of being technology agnostic in our criteria. Having a profile would separate the FIDO-ness from the principles of the base criteria – a separate SAC would be produced which CSPs /Agencies would elect to employ and the specific provisions of the profile would overlay the baseline 63B criterion. In other words, the 63B_SAC need not change.
If this notion gains support I’m happy to draft a 63B_FIDO_SAC for the IAWG’s consideration. I reckon this is the way to go. Until tomorrow, …
*Richard G. WILSHER CEO & Founder, Zygma Inc. www.Zygma.biz <http://www.Zygma.biz> +1 714 797 9942*
*From:* Jimmy Jung [mailto:jimmy.jung@slandala.com] *Sent:* Wednesday, October 16, 2024 01:28 *To:* Amanda Gay; wg-idassurance@kantarainitiative.org *Subject:* [WG-IDAssurance] Re: Invitation and Agenda - IAWG - 17 October 2024
Amanda, folks,
Attached please find a cleaner updated version. Again, selecting in column Q shows the related criteria, with actual changes in RED font.
*From:* Amanda Gay <amanda@kantarainitiative.org> *Sent:* Tuesday, October 15, 2024 3:38 PM *To:* wg-idassurance@kantarainitiative.org *Subject:* [WG-IDAssurance] Invitation and Agenda - IAWG - 17 October 2024
Dear IAWG Members:
Please join us Thursday, October 12th, 12PM ET for our next IAWG meeting.
The proposed agenda and Zoom details are below.
*Date and Time*
· *Date: Thursday, 2024-10-17*
· *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://zoom.us/u/abUx61ivsc>
o Need to add IAWG meetings to your calendar? Do so here! <https://kantara.atlassian.net/wiki/spaces/IAWG/overview>
*DRAFT 10.17.2024*
*1. Administration:*
o Roll call, determination of quorum.
o Minutes approval
§ 2024.10.10 Minutes DRAFT <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/689242133/2024-10-10+IAWG+Meeting+Notes+DRAFT>
§ 2024.10.03 Minutes DRAFT <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/680329217/2024-10-03+IAWG+Meeting+Notes+DRAFT>
§ 2024.09.26 Minutes DRAFT <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/616497192/2024-09-26+IAWG+Meeting+Notes+DRAFT>
§ 2024.09.19 Minutes DRAFT <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/616661030/2024-09-19+IAWG+Meeting+Notes+DRAFT>
§ 2024.09.05 Minutes DRAFT <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/616661008/2024-09-05+IAWG+Meeting+Notes+DRAFT>
o Kantara Updates
§ DEIA Survey <https://www.surveymonkey.com/r/3LPP3WL> Open to Responses
o Assurance Updates
2. *IAWG Actions/Reminders/Updates:*
- Meeting cadence - weekly. - Final NIST Comments <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/689537027/800-63+rev.+4+2PD+Comments+from+IAWG>
3. *ISO 17065 Discussion Items*
4. *Group Discussion: *
- Proposed syncable authenticator criteria from Richard/Jimmy (Found in Meeting Materials <https://kantara.atlassian.net/wiki/spaces/IAWG/pages/353632257/2024+Meeting+Materials> on IAWG Wiki and attached).
- Review any comments/continued discussion
--
*Amanda Gay | Administrative Coordinator*
*Twitter:* @KantaraNews
*LinkedIn:* @KantaraInitiative
**Please take a few minutes to complete the third annual DEIA survey <https://www.surveymonkey.com/r/3LPP3WL>!**
_______________________________________________ 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