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?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:
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
+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)
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
o Need to add IAWG meetings to your calendar? Do so here!
DRAFT 10.17.2024
1. Administration:
o Roll call, determination of quorum.
o Minutes approval
o Kantara Updates
§ DEIA Survey Open to Responses
o Assurance Updates
2. IAWG Actions/Reminders/Updates:
- Meeting cadence - weekly.
- Final NIST Comments
3. ISO 17065 Discussion Items
4. Group Discussion:
- Proposed syncable authenticator criteria from Richard/Jimmy (Found in 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!*
_______________________________________________
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@kantarainitiative.org/
______
Group wiki -- https://kantara.atlassian.net/wiki/spaces/WG-IDAssurance