Apologies for this even later contribution to today’s meeting, but  …

On the last call which in which I was a participant I made a statement which I’d like to reiterate, for good reason (imo!):

Kantara’s purpose is to give assurance to RPs and the user community at large that services which we assess and Approve can be relied upon to the extent of the criteria and assessment processes applied.  While we may use NIST’s 800-63 series as a very significant technical driver for our criteria, we have in the past exercised judgement in the creation of Kantara’s criteria in order to reflect practical and commercial realities.  Indeed, my ongoing review of -63A rev.4 convinces me that we need to continue to exercise that judgement!

My point therefore was that we should NOT be beholden to NIST’s publications but do what is responsible whilst being responsive to our primary customers – CSPs who have services for which they wish to demonstrate conformity and thus Approval.  In doing so, we need to take an approach towards NIST’s 63B Supplement which provides for recognition of its good parts and to deal with the difficulties which remain, and my understanding thus far is that 63B rev.4 does not materially advance what is in the Supplement (open to education if that is not a valid assertion).

An obvious aspect in this is that there are things occurring within the sync.authr fabric over which CSP’s have no control and therefore our existing criteria demand a finding of nonconformance where criteria have requirements for CSPs to do certain things which they are simply unable to effect, which would (could?) lead to Approval not being granted.

I am also mindful of our objective to keep our criteria ‘technology agnostic’.

All that said, I’d like to float an idea:

Given their increasingly ubiquitous usage, not least by agencies who seem to want to put them to use despite how they may or may not meet NIST’s published expectations, and noting that a good number of our CSPs want to deploy such authenticators within the scope of their services, in order to get passkeys / FIDO / syncable authenticators out the door, can we state the following in the guidance section for those criteria where things are taken out of the CSP’s hands?

Where FIDO-specific authenticators are implemented within a policy/technical/operational fabric wherein:  a)  the CSP is unable to exercise any control over the authenticator implementation; and b) the CSP has no insight into said implementation; then the 'SoCA' entry for this criterion SHALL be cited as follows:

"In scope - Not applicable:  Authenticator fabric beyond [service name]'s scope of control - see [KI notice]"

 

Implicitly therefore, Kantara needs to publish a notice to the effect that, given the pressure from service consumers to deploy FIDO-implemented passkeys, and in recognition of the fact that CSPs cannot be held responsible for the implementation of the operational infrastructure, Approval of services which deploy FIDO passkey authenticators DOES NOT extend to the assurability of the FIDO fabric.  Furthermore, Kantara should affirm that any other form of authenticators deployed by a specific service DO fall within the scope of any Approval which has been awarded to that service.

By publishing this notice and it being referenced from the SoCA (part of the TSL) and perhaps more explicitly also from a specific field in the primary entry for the Approved service, it should be abundantly clear to anyone genuinely interested in a service, as either a consumer (RP) or as a subject, that there’s stuff we cannot control but everybody wants.  This also avoids writing a non-agnostic criterion (or two) which directly refers to FIDO – it is the SoCA which delivers the technology-specific notice. 

Jimmy has already provided some draft criteria in response to the Supplement and he and I have colluded to bring those along a bit further BUT … they can only go so far and serve no purpose unless we address the elephant in the room.

I might add, I see this as a short-term solution, the longer-term goal being to encourage the establishment of a means to evaluate and affirm the correctness of FIDO implementations.  Not KI’s job, imo. Someone else’s, but we should offer encouragement.

Food for thought, along with the grist for the mill?

 

Richard G. WILSHER
CEO & Founder,  Zygma Inc.
www.Zygma.biz
+1 714 797 9942

 

_______________________________________________
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