Jimmy: Relying party definition: For Kantara’s purposes, the relying party is the CSP. An entity identifies somebody, and it’s accepted (a passkey will be the authenticator). The entity is not issuing an authenticator, as one is already present and it is accepted by the entity. Now the CSP is the relying party on the passkey.
Tim: 90~% of cases, the IDP and the relying party are the same.
Jimmy: Since the CSP/relying party is now dependent on the authenticator,but what (if any) control do they have over the bar that is set for this authenticator?
The authenticator was already set in the browser, so theoretically the CSP can say “no” or accept something that’s below their usual standards.
Tim: Decision–add more friction. If you get a sync passkey (all that is available)--it would be stated in risk policy if that is good enough, or if further action is needed. Notes a huge difference between workforce and consumer. Workforce-users use what you tell them (no issue). Unmanaged consumer devices are another story
Alexei: Concern comes from knowing whether the passkey has moved devices and less from whether the passkey syncs. That’s where a step-up would be requested.
Jimmy: How does Kantara deal with this supplement?
Alexei: The reality is that you can either use passkeys or not, and if you choose to use them-they need to be used the way that the passkey providers are providing them. NIST seems to think it is better to use them than not.
Tim: The goal is to remove passwords from the Internet, so a new default credential is needed that is better, hence sync passkeys.
Jimmy: Implementation seems to be something that happens before the CSP gets involved (syncable or otherwise). We don’t get the option to enforce the policy that we think is correct-the decision RE: authenticators happens before we get involved.
Tim: If policy were enforced, 95% of users would fail–default authenticators would be sync passkeys.
Dean: No a priori way to say create a synced or device bound passkeys. That functionality doesn’t exist in the standards today. Because that does not exist, relying parties are put in the position of accept what we get and then decide do I trust it as is, or use another factor to go with it
Dean: If you dig into the supplement, it says you are an AAL2 credential if you can demonstrate the following properties–in the synced passkey realism, there is no broadly available mechanism to address what these properties are about (synchronization account, recovery, etc). This type of information is available in many cases for device-bound/hardware credentials. It is a W3C issue.
Tim: It is not a W3C issue, FIDO Alliance is unable to reach a consensus with its members.
Richard: It seems that the fundamental issue is that a CSP which wishes to rely upon these credentials has no way of knowing that the implementation is sound. We have algorithms/test programs for things like buyer matching to ensure that things are fulfilled, but there is no such availability for pass keys. So how do we assess the CSP with any level of confidence if they are using passkeys? We know it’s a reliable implementation because there is some evidence.
Tim: You can request an attestation and authenticators provide attestation–you will get this and can make decisions based on this data. Some passkeys will not have attestation and that gives you a baseline security bar for those passkeys (this is phishing resistant/a credential check), but that’s all. It is better than a password.
Richard: This seems to be self-attestation. Why would I rely on one more thant hte other? How would I know which one has at least met a minimum standard?
Tim: The protocol is giving the phishing resistance, which is the base level (phishing resistant credential with no other statements about security). This is better than today’s current procedures. If you/the user/consumer use a security key, then you get an attestation (the protocols and standards haven’t changed). You look up the attestation/identifier in FIDO, MDS, and decide which level it fits, what it does (ID verification) and if the key is hardware bound or not. This may be the point of acceptance.
Yehoshua: So you don’t get the option to make your own independent decisions based on the NIST standards because you have to meet certain underlying criteria? So in a pure non-compliance based, general security way, you can say-this is better. But how do you check to say that it does meet all of these things?
Tim: “If-then, Then-this”--If there is no attestation, you can assume that the credential is phishing resistant. If there is an attestation, you can run a validation loop to determine the type of authenticator with X properties and it is phishing resistant/validated/certified. You then decide if that context is important in your particular case.
Alexei: Cites the importance of mass deployment without lowering the security bar, which passkeys do. Notes/recommendations back to FIDO are recommended, but in general, passkeys are a great opportunity.
Hughes: The challenge IAWG faces is how to assess a CSP against the subset of NIST requirements (if you use passkeys, you need to do these things) based on some evidence pulled from the current matrix of assurance levels. We can assess controls/policies/passkeys on the CSP side, but we can’t assess passkeys on the user’s device side. We also can’t assess federal agencies. Where are the observable things we can get at? Is it enough to say the CSP must have a policy?
Dean: Every passkey (device bound or synced) hits AAL1 ( single factor)--we can treat them the same way we treat passwords. They meet the AAL1 and they are better than passwords. The question becomes when AAL2 is needed. What evidence is needed and how do I get that evidence? There likely will not be any AAL2 credentials from consumers (unless they have a hardware/device bound key), because they won’t meet the AAL2 bar (no attestation which tells the relying party the properties of that credential that they can depend on.
Dean: This has been a significant topic of discussion within FIDO Alliance-how to get some assurance around these passkeys (device-bound or syncable). How do we get an attestation or some other statement of fact that tells us the properties of those credentials that then allows us to go back and map against something like 800-63B. The goal would be to find evidence that shows a passkey is AAL2 or AAL3 compatible credential. Sometimes this is a hardware key. But the gap today is in synced passkeys where you don’t have that evidence in most cases (there are some limited cases where you can find the evidence but they are not available in the consumer market).
Tim: The last formal proposal to address this did not move forward. The main challenge with consumer/user authenticators is privacy. Knowing a 6 digit pin could be invasion of privacy, tracking vector/fingerprinting vector. This is very different from an employee security key with an 8 digit pin (no expectation of privacy).
Jimmy: We have to know if it is a 6 or 8 digit PIN or we can’t declare it Kantara/63 compliant. NIST did not adjust this criteria. We can’t know it, nor can we know syncability and we can’t enforce it. So passkeys can’t be compliant.
Yehoshua: The CSPs can’t know it either, so the CSP can’t do anything nor can they accept it.
Hughes: Alexei—What does a CSP do that accepts syncable passkeys?
Alexei: There are different types of CSPs in different markets (regulated/unregulated) and some CSPs have a single account that a user can access across everything from prescriptions to burrito discounts. So it depends. The desire is to be able to use these things in all types of places.
Hughes: Restatement - Phishing resistant authenticators have no issue at AAL1 (better than a password/superior form of authentication that eliminates the need for passwords). The additional security controls around AAL2 that are possible in enterprise deployments are unlikely to exist in consumer environments. This is a great market opportunity if someone can figure out how to assess the conformity to 800-63B.
Dean: Concurs. Kantara’s question is what are the things I need to observe in order to state that this is compliant at AAL2. This is somewhat laid out in the supplement (issues with language), but it requires knowing a priori that the passkey has these properties because I helped the user register or at registration time, having a signal about the properties of the passkey passed to the relying party. This could be via attestation (most hardware keys today) that allows you to observe the credential properties-whether it’s device bound or meets FIPS 140,etc. So that’s the space to work in to figure out how to obtain the needed evidence each and every time.
Hughes: The assessors are allowed to ask the CSP how do you know that the consumer passkey has not only MFA, but AAL2 MFA-you don’t on the syncable. If we can’t assess that, what can we do?
Dean: List (General requirements for all uses of syncable authenticators): We see that the things we can get assurance about from a synced passkey provider in the consumer space is all keys using approved cryptography. An RP decides which cryptosystems are in use and suitable for your use.
Alexei: Can you anticipate entropy/randomness?
Tim: No synced passkey today will meet this and likely won’t for at least two years. Efforts were made to try to give more guidance, but didn’t make it through the process. The result is that users are going to use worse off authentication methods because they must have these properties, or they are going to take their own interpretation and use a synced passkey, which is ultimately a better approach (cost, user experience, and security). This is slightly different due to needing to certify, but there doesn’t seem to be anything to certify at the moment.
Alexei: Seems that an unrealistic bar for passkeys when we don’t do other types of certifications (phone password, operating systems, syncing cookies, etc), which can ultimately disenfranchise consumers. And passkey providers are going to make their own decisions. So the space is that an enterprise bar has been set for consumer deployment and passkey providers are going to do it their way.
Hughes: So is this confirming the factor that some of the mandatory requirements are not achievable in today’s market? The tech is there but implementations don’t exist yet for consumers?
Dean: It is achievable but any 3rd party pass key provider will likely be blocked by dominant browsers.
Tim: Not blockable, but no one is going to go first. The use of passkeys is intended to eliminate passwords. If a user can’t create a passkey-you can’t tell them to go get something else. Baseline solution is needed.
Richard: Alexei’s point of disenfranchising the consumer market-it’s not that these are technically achievable, it’s whether they can be demonstrably achieved. Is there a basis on which adherence to particular set of policy statements or technical specifications can be independently verified/proven? From an assessor’s point of view-there is no basis to say we trust this one, but not that one. The difficulty is we can’t prove workability at AAL2.
James: Can we audit this as written?
Tim: Yes in a managed context. These would not be authenticators on people’s devices by default. Criteria also states that you are evaluating default services on devices, so that’s a different requirement.
Dean: Yes, you can assess it, but everyone would fail in the consumer market because there is no evidence that would get you to AAL2.
Roger: What will Kantara do? The govt has made suggestions. Will Kantara push back, or try to figure out what combination of evidence will possibly satisfy those additional controls?
Yehoshua: Seeing a paradigm that passkeys came into existence to replace passwords as a stronger alternative. NIST sees PKI based credentials when they look at passkeys and they think it affects their PKI authenticator things and so they are seeking to apply different PKI controls versus just looking at it as a password replacement. Which means NIST goals are not going to match the passkey goals because the end game is 2 different things.