"invalid fidoCredType" After changing FidoCredType from FIDO to Passkey

Products

• VIP Authentication Hub

Issue/Introduction

- Upgrading from 2.2.x to 3.3.x AuthHub

- Previously within 2.2.x,  fidoCredType = FIDO and useFqdn = true were used to register PASSKEY 

- After upgrading from 2.x to 3.3.x release of the AuthHub when trying to use the new fidoCredType = PASSKEY  instead of the old method FIDO, the following Error is received 

 

{"errorCode":"2003019","errorMessage":"invalid fidoCredType"} 

 

- To use FIDO passkey Registration flow  /factor/v1/FIDORegChallengeGenerator  , we are using the below request payload. 

 

       {

         "documentDomain":"https://www.example.com",

         "userName": "*****",

         "deviceName": "example1",

         "fidoCredType" : "PASSKEY",

         "useFqdn" : "true"

       }

 

 

Same for the FIDOAuthChallengeGenerator API 

 

      {

        "documentDomain":"https://www.example.com",

        "userName": "******",

        "fidoCredType" : "PASSKEY",

        "useFqdn" : "true"

   }

 

 

Resolution

The use of useFqdn with the fidocredtype as PASSKEY is what is causing the issue.

fidoCredType = PASSKEY was introduced in 3.3 release --> https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/3-3/Release-Notes/release-notes-3-3.html

In this release, to register a new passkey, you need to update or create an Authentication policy which contains passkey as a factor.

The "useFQDN" setting which was introduced in Authentication Hub v2.2, is now used solely for backward compatibility. Therefore, it is only applicable during authentication (using the ".../factor/v1/FIDOAuthChallengeGenerator" and ".../factor/v1/FIDOAuthChallengeVerifier" APIs) for devices that have already registered passkeys.

so Prior to 3.3 , you had to pass  "useFQDN==true" and "fidoCredType=FIDO" combination  so AuthHub can take it as passkey.

This no longer needed in 3.3, only fidoCredType = PASSKEY is needed in the registration and auth Challenge APIs.

The Passkey registered prior to version 3.3 using fidoCredType as FIDO and useFQDN == true should continue to work for authentication scenarios. So after upgrading to AH 3.3, while authenticating OLD passkey registered, you have to send fidoCredType as FIDO and useFQDN == true in the /factor/v1/FIDOAuthChallengeVerifier in API call.

But you will not be able to register new PASSKEY credentials using fidoCredType as FIDO and useFQDN == true combination. With AH 3.3, it is mandatory to register and authenticate new PASSKEY credentials with fidoCredType as PASSKEY and a new auth policy containing PASSKEY as obligation. 

The following tables summaries the OLD passkey behavior (Passkey registered using fidoCredType = FIDO and useFQDN = true). So, users will continue to authenticate using OLD passkey credentials registered prior to 3.3 (to maintain backward compatibility) but to create a new PASSKEY credential, the application must send the fidoCredType as PASSKEY.

 

OLD Passkey registration after upgrading to 3.3

 

Existing fidoCredType	useFQDN flag	fidoCredType after upgrade	Expected FIDO registration result
FIDO	false	FIDO	Credential will be registered as FIDO credential
FIDO	true	FIDO	Credential will be registered as FIDO credential. Note: The API factor/v1/FIDORegChallengeGenerator will ignore the useFQDN flag.

 

OLD Passkey authentication after upgrading to 3.3

Existing fidoCredType	useFQDN flag	fidoCredType after upgrade	Expected auth result
FIDO	false	FIDO	Continue to work as expected
FIDO	true	PASSKEY	It will work as PASSKEY credential. For backward compatibility reasons, factor/v1/FIDOAuthChallengeVerifier API will allow CredType == FIDO and useFQDN == true as PASSKEY

 

NEW Passkey registration after upgrading to 3.3

fidoCredType	Expected registration result
PASSKEY	Credential will be registered as PASSKEY credential

 

NEW Passkey authentication after upgrading to 3.3

fidoCredType	Expected auth result
PASSKEY	It will be authenticated as PASSKEY credential.