Desktop SDK

The Arculus FIDO SDK for Desktop provides a Java API for FIDO2 authentication using PC/SC-compatible NFC readers and Arculus cards. The SDK handles all complexity of attestation object creation, cryptographic operations, and server communication.

Key Features:

  • Simple synchronous API

  • PC/SC reader support (Windows, macOS, Linux)

  • Direct FIDO2 server communication or card-only operations

  • Built-in attestation payload construction

  • Cross-platform support

Obtaining the SDK

Contact your Arculus representative to obtain the Desktop SDK distribution package. The package includes:

Component
Description

ArculusFidoSDK-1.0.0.jar

Core FIDO2 SDK (fat JAR with bundled dependencies)

ArculusPCSC-1.0.0.jar

PC/SC smart card reader interface

Sample Applications

Complete Java desktop apps demonstrating SDK usage

API Documentation

JavaDoc documentation for all public APIs

The Desktop SDK is distributed as JAR files that can be added to any Java 8+ project. See 5.4 Desktop Sample Applications for complete sample code.

2.5.1 Installation

Requirements

  • Java 8 or later

  • PC/SC-compatible NFC reader (e.g., OMNIKEY 5422, ACR122U)

  • Physical Arculus FIDO2 card

  • PC/SC libraries installed on your system

Adding the JAR Library

  1. Copy the Arculus FIDO SDK JAR files to your project:

    • ArculusFidoSDK-1.0.0.jar - Core FIDO2 operations (fat JAR - includes dependencies)

    • ArculusPCSC-1.0.0.jar - PC/SC smart card reader interface

Note: The ArculusFidoSDK-1.0.0.jar is a "fat JAR" (shadow JAR) that includes all required dependencies internally. This means you may not need to add all dependencies explicitly, depending on your build configuration.

  1. Add dependencies to your build configuration (Maven/Gradle):

Maven:

Gradle:

Dependency Strategy:

  • Fat JAR Approach (Recommended for simplicity): The ArculusFidoSDK-1.0.0.jar includes all dependencies. Just add the JAR files and you're ready to go.

  • Explicit Dependencies (For version control): If you need specific versions or want to manage dependencies explicitly, add the dependencies listed above. The fat JAR will still work, but your explicit dependencies will take precedence if there are version conflicts.

Basic Setup

2.5.2 Registration Flow

Registration creates a new FIDO2 credential and stores it on both the Arculus card and the FIDO server.

The Desktop SDK supports two deployment patterns: client-direct (direct FIDO2 server communication) and backend-proxied (backend services proxy FIDO2 requests).

Client-Direct Pattern

In client-direct deployments, the desktop application communicates directly with the FIDO2 server.

API Signature

Parameters

Parameter
Type
Description

fidoServer

ArculusFidoServer

Server configuration object

pin

String

6+ digit PIN for the card

username

String

User identifier (e.g., email)

displayName

String

Human-readable name

relyingParty

String

Relying party ID (domain)

resetDevice

boolean

If true, resets card and sets PIN

registrationInfo

String

Optional device metadata JSON

Example

Backend-Proxied Pattern

In backend-proxied deployments, the desktop application communicates with backend services that proxy FIDO2 requests. This provides enhanced security by isolating the FIDO2 server from client applications.

API Signature

Parameters

Parameter
Type
Description

pin

String

6+ digit PIN for the card

username

String

User identifier (e.g., email)

displayName

String

Human-readable name

relyingParty

String

Relying party ID (domain)

challenge

String

Base64-encoded challenge from backend's /register/begin response

origin

String

Origin URL for clientDataJSON (typically FIDO2 server URL)

Note: Unlike authenticateCardOnly(), registerCardOnly() takes challenge and origin directly rather than an optionsResponse object.

Helper Functions: The backend-proxied pattern requires helper classes and functions for backend communication and response transformation. See Backend Integration Helpers for complete implementations of BackendApiClient and createOptionsResponseFromBackend().

Phase 1: Get Challenge from Backend

Phase 2: Perform Card Registration

Phase 3: Complete Registration with Backend

Note: In backend-proxied deployments, the desktop application performs only card operations. All FIDO2 server communication is handled by your backend services. Unlike authenticateCardOnly(), registerCardOnly() takes challenge and origin directly rather than an optionsResponse object.

Registration Sequence Diagrams

Client-Direct Pattern

spinner

Backend-Proxied Pattern

spinner

2.5.3 Authentication Flow

Authentication verifies a user's credential stored on the Arculus card.

The Desktop SDK supports two deployment patterns: client-direct (direct FIDO2 server communication) and backend-proxied (backend services proxy FIDO2 requests).

Client-Direct Pattern

In client-direct deployments, the desktop application communicates directly with the FIDO2 server.

API Signature

Parameters

Parameter
Type
Description

fidoServer

ArculusFidoServer

Server configuration object

pin

String

Card PIN

username

String

User identifier

displayName

String

Human-readable name

relyingParty

String

Relying party ID (must match registration)

Example

Backend-Proxied Pattern

In backend-proxied deployments, the desktop application communicates with backend services that proxy FIDO2 requests. This provides enhanced security by isolating the FIDO2 server from client applications.

API Signature

Parameters

Parameter
Type
Description

pin

String

Card PIN

username

String

User identifier

relyingParty

String

Relying party ID (must match registration)

optionsResponse

ArculusFidoOptionsAuthorizationResponse

Pre-constructed options response containing challenge from backend

Returns: AuthenticateCardSignResponse object containing id, rawId, authdataBase64, and signatureBase64.

Note: Unlike registerCardOnly(), authenticateCardOnly() uses an optionsResponse object that must be constructed from the backend's response.

Phase 1: Get Challenge from Backend

Phase 2: Perform Card Authentication

Phase 3: Complete Authentication with Backend

Note: The authenticateCardOnly() method performs only card operations and returns an AuthenticateCardSignResponse object containing the real signature and authenticator data. All FIDO2 server communication is handled by your backend services.

Authentication Sequence Diagrams

Client-Direct Pattern

spinner

Backend-Proxied Pattern

spinner

2.5.4 PIN Management

Set PIN (Reset Card)

Resets the card and sets a new PIN. Warning: This erases all credentials on the card.

Example:

Change PIN (Preserve Data)

Changes the PIN while preserving all credentials on the card.

Example:

2.5.5 Reader Management

List Available Readers

Select Specific Reader

Note: For OMNIKEY readers, prefer the contactless (CL) interface for NFC operations.

2.5.6 Error Handling

Response Format

All methods return a JSON string:

Or on failure:

Error Handling Example

Common Error Codes

Code
Description
Resolution

600

Tag lost

Keep card on reader during operation

602

No credentials

Register card first

608

PIN failed

Check PIN is correct

611

Set PIN failed

Retry operation

615

Reader not available

Check PC/SC reader connection

E2017R

Invalid signature

Credential may be corrupted

E2019R

Unknown credential

User not registered

See 2.7 Error Codes for complete reference.

ArculusFidoServer Class

Configure server connection details:

Server Methods

Method
Description

setRequestProperty(key, value)

Add custom HTTP header

setDeviceinfo(json)

Set device metadata for registration

Helper Classes

ArculusFidoOptionsAuthorizationResponse

Used in backend-proxied deployments to construct options from backend responses:

AuthenticateCardSignResponse

Returned by authenticateCardOnly() method:

Complete Sample Application

For complete Desktop sample applications demonstrating both client-direct and backend-proxied deployment patterns, see 5.4 Desktop Sample Applications in the Appendix.

Last updated