A bulletin board used to document issues, problems, program bugs, workarounds, and user comments. Program bugs happen! Operational edge conditions may go undetected by SQA. Suggestions for improvements are common. As are general complaints. We respect them all, post them here alongside comments, workarounds, rebuttals, and apologies.

This is also where you’ll learn about new release updates, new features, and what improvements and new features we’re working on.

We try not to delay responses longer than necessary, but our priority is given to operational issues and difficulties.

1. Cell phones configured to operate hybrid calling plans such as Xfinity may experience frequent switching between Wi-Fi and cellular when used in locations with marginal Wi-Fi service. The disruptive internet access that results impacts authentication apps such as AffirmedID that rely on consistant internet access. There is no known remedy for this condition.

2. Recent changes by Apple and Google to throttle BLE use as part of their privacy campaigns forced a redesign of AffirmedID’s active proximity detection. This is an ongoing project. Passive proximity is operational and available for CAM use.

3. Dashboard tools for integrating and maintaining client OIDC and SAML integrations are scheduled for Q4 availability. Integration services are provided until dashboard availability.

At present we are working on tools to streamline the SAML 2.0 and OIDC integration process for MSP integrators. Expect to see the fruits of this effort in Q4 2025. While this project proceeds on its path, we provide integration services at no cost to assist early adopters. You can learn more about those services and the tools being developed by subscribing to the integration email list .

OIDC Integration

The OIDC client application deployment is a straightforward process of configuring the AffirmedID provider and the client application. Semi-automatic facilities are available on your assigned dashboard, End User or MSP, to do so. You’ll need a registered AffirmedID account for login. Go to app download and register an account if you’ve not already done so.

Use your dashboard, End User or MSP, to configure an OIDC deployment. Help Desk assistance is available if needed.

Confidential Client OIDC Integration

During the registration and integration process, login into the MSP or SMB dashboard using your AffirmedID account and go to the OIDC configuration tab. Complete the form providing all ‘required’ field information.

• Redirect URIs: A list of your URIs where the provider is allowed to redirect the user after authentication. This is a critical security measure.
• Response Types: Defaults to ‘code’.
• Grant Types: not used.
• Token Endpoint Auth Method: Defaults to ‘client_secret_basic’.
• Application Type: Can be set to web or native to indicate the type of application.
• Client Name: A human-readable name for the client application.

Tap Submit. In the response display:

• Client ID: A unique identifier assigned to the client by the provider.
• Client ID Issued At: The timestamp when the client id was issued.
• Client Secret: A confidential, randomly generated string that the provider issues. Do not disclose and store this secret securely.
• Client Secret Expires At: An expiration timestamp for the secret, if applicable.
• Registration Access Token: An access token that can be used to manage the client's registration (e.g., to update its metadata).
• Registration Client URI: The URI that can be used to retrieve or update the client's registration.

Use the response values provided to configure the client application.

Public Client OIDC Integration

The best method for MSP or SMB integrations is using their respective dashboard. During the integration registration process, login in to the dashboard using your AffirmedID account. Complete the form providing all ‘required’ field information.

• Redirect URLs: A list of URIs where the provider is allowed to redirect the user after authentication. This is a critical security measure.
• Response Types: Defaults to ‘code’.
• Grant Types: not used.
• Token Endpoint Auth Method: Defaults to ‘none’.
• Application Type: Can be set to web or native to indicate the type of application.
• Client Name: A human-readable name for the client application.
• Logo URI: A URI for the client's logo.

Tap Submit. In the response display:

• Client ID: A unique identifier assigned to the client by the provider. This is the most important piece of information exchanged.
• Client ID Issued At: The timestamp when the client id was issued.
• Client Secret: Default, left blank.
• Client Secret Expires At: Default, left blank.
• Registration Access Token: An access token that can be used to manage the client's registration (e.g., to update its metadata).
• Registration Client URI: The URI that can be used to retrieve or update the client's registration.

Use the response values provided to configure the client application.

SAML 2.0 Integration Support

TBA

Sidecar Integration Library

The sidecar library stands alongside the WebAuthN standard FIDO2 Client library used when performing FIDO2 or Passkey authentication ceremonies. It works identically to the FIDO2 Client library with one exception.

Standard FIDO2 and Passkey implementations form a bond extending from RP to Access Device to Browser to Authenticator Device. Extremely effective phishing-resistant authentication ceremony security at the expense of UX and increased help desk support needs.

Sidecar forms a bond that extends from RP to Application to Cloud Service to Authenticator Device to User and Access Device. Superior phishing-resistant authentication security without sacrificing UX and incurring increased help desk support. The exception is Application, which may be an access browser, as is normal for Passkey but could be any application with internet access.

The Benefits of Federated Architecture are many. Here are just a few examples.

The federation of a single ceremony creates a framework within which integration of the FIDO2 device identity assertion and evidence of user identity can occur. The result ensures compliance with the strict NIST requirements for AAL3 MFA for all user accounts of all RPs.

Through federation, recovery from the loss of a cell phone takes the user just minutes to complete without the need for help desk assistance. Without federation, restoration can take several hours or even days, often with substantial help desk impacts.

User mobility is becoming a necessity, and through federation it's assured no matter how many RPs or RP user accounts a user may have. The non-federated user is left with one account per RP user account, a nightmare for the user, help desk, and management.