Privicore
  1. Verified authenticator
Privicore
  • Privicore API
  • Utility
    • Utility
    • Check server health
      GET
    • Request command id status
      GET
  • Profile
    • Profile Model and Authentication Workflow
    • Register new profile
      POST
    • Authenticate
      POST
    • Retrieve profile id
      GET
    • Change password
      POST
    • Generate qr token for authorization
      POST
    • Reauthorize authorization token
      POST
    • Revoke authorization token
      POST
    • Retrieve token expiry
      POST
  • OAuth Application
    • OAuth Application Management
    • Register OAuth Application
      POST
    • Retrieve OAuth app configuration
      POST
    • Request OAuth app authorization code
      GET
    • Retrieve OAuth app authorization code
      POST
    • Obtain OAuth app access token
      POST
    • OAuth application list
      GET
    • Retrieve OAuth application scope
      GET
    • Refresh OAuth app access token
      POST
  • Public key
    • Public and Private Key Management
    • Generate your private and public keys
    • Register public key
    • Retrieve public key
    • Retrieve CAB public key
  • Data Token
    • Data Token Management
    • Reserve token space
    • Retrieve temporary data token
    • Exchange data for token
    • Upstream file via stream auth
    • Request data via token
    • Download data
    • Configure information security risk meta
    • Configure file meta
    • List data tokens
    • Update data token
    • Delete data
  • Device
    • Device Management
    • Request unique identifier (i.e. Register new device)
    • Retrieve unique identifier
    • Retrieve profile devices
    • Configure device meta
    • Approve device
    • Reject device
    • Retrieve device configuration
    • Remove device
  • Storage
    • Storage Device Management
    • Register storage device
    • List storage devices
    • Synchronize device
    • Remove storage
  • Verified authenticator
    • Authenticator and Voting Management
    • Register authenticator
      POST
    • List verified authenticators
      GET
    • Retrieve voting strategy
      GET
    • Set quorum size
      POST
    • Set quorum strategy
      POST
    • Set voting time limit
      POST
    • Set maximum voting attempts
      POST
    • Remove authenticator
      POST
    • Register voting configuration
      POST
    • Update voting configuration
      POST
    • List voting configurations
      GET
    • Retrieve voting configuration
      GET
  • Policy
    • List policy templates
    • Register policy
    • List active policies
    • List inactive policies
    • Activate policy
    • Deactivate policy
    • Delete policy
    • List registered policies
    • Retrieve registered policy
  • Directory
    • Register Directory
    • Retrieve owned Directories
    • Retrieve assigned directories
    • Retrieve Directory
    • Create Directory User
    • Update user information
    • Invite Profile
    • Set profile password
    • List Directory Invites
    • Process Invitation
    • Retrieve directory profile
    • List directory users
    • Directory profiles info
    • Create profile device
    • Add storage device to profile
    • List directory devices
    • Create directory voting pool
    • Store directory meta information
  • Voting
    • Create voting
    • Check pool status
  • Schemas
    • Response
      • CommandAccepted
      • Unauthorized
      • ValidationErrors
    • Schemas
    • profileId
    • deviceIdentifier
    • directoryId
    • directoryName
    • directoryShortName
    • givenName
    • familyName
    • createdAt
    • meta
  1. Verified authenticator

Authenticator and Voting Management

Introduction#

Authenticators are specialized devices that participate in policy-driven voting workflows within Privicore. The voting mechanism enables interactive authorization for asynchronous operations, providing flexible approval processes for security-sensitive actions.

What Are Authenticators?#

An Authenticator is a registered device that:
Receives ballots for voting on system operations
Enables user interaction for approval/rejection decisions
Participates in policy-triggered authorization workflows
Can operate as automated decision-making agents
Works independently or in combination with Storage functionality

How Voting Works#

Policy-Triggered Voting#

Privicore operations are asynchronous and can be interrupted by voting mechanisms when policies require authorization. The voting workflow:
1.
Policy Evaluation: A system operation triggers a policy check
2.
Poll Creation: If policy requires voting, Privicore creates a poll
3.
Ballot Distribution: Ballots are sent to registered Authenticator devices via RabbitMQ
4.
User Response: User or automated software responds with approval (yes) or rejection (no)
5.
Vote Collection: Privicore collects votes from Authenticators
6.
Poll Resolution: Poll is resolved according to the configured voting strategy
7.
Operation Continues or Fails: Based on poll outcome, the original operation proceeds or is denied

Voting Components#

Poll#

A poll represents a single voting session for a specific operation. Each poll contains:
Operation Context: What action requires authorization
Ballots: Individual voting requests sent to each Authenticator
Time Limit: How long voting remains open
Strategy: How votes are counted and resolved

Ballot#

A ballot is a voting request sent to a specific Authenticator device. Each ballot:
Describes the operation requiring approval
Provides context for decision-making (location, time, requester, etc.)
Awaits yes/no response from the Authenticator
Has an individual timeout period

Quorum#

Quorum defines the minimum number of Authenticators that must respond for a poll to be valid. If quorum is not met, the poll fails regardless of vote outcomes.

Voting Strategies#

Voting strategies determine how votes are counted and when a poll succeeds or fails:

Unanimous Strategy#

All responding Authenticators must vote "yes" for the poll to succeed.
Use Case: Critical operations requiring complete consensus (e.g., account deletion, security policy changes)

Majority Strategy#

More than 50% of responding Authenticators must vote "yes" for the poll to succeed.
Use Case: Standard approval workflows where general consensus is sufficient

Single Approval Strategy#

At least one Authenticator must vote "yes" for the poll to succeed.
Use Case: Convenience-focused workflows where any authorized device can approve (e.g., login confirmation)

Threshold Strategy#

A specific number or percentage of Authenticators must vote "yes" for the poll to succeed.
Use Case: Custom scenarios requiring precise control over approval requirements (e.g., 3 out of 5 devices, or 75% approval)

Voting Configuration#

Voting behavior is controlled through configurable parameters:

Quorum Size#

The minimum number of Authenticators that must respond to a poll. If fewer than this number respond, the poll fails.
Example: Quorum size of 2 means at least 2 Authenticators must cast votes.

Voting Time Limit#

Maximum duration a poll remains open for voting. After this time expires, the poll resolves with available votes or fails if quorum is not met.
Example: 5-minute time limit means users have 5 minutes to respond on their Authenticator devices.

Maximum Voting Attempts#

Number of times a poll can be retried if it fails due to timeout or rejection.
Example: Maximum attempts of 3 allows the system to re-create the poll twice after initial failure.

Strategy Selection#

Determines which voting strategy (unanimous, majority, single approval, threshold) is applied to the poll.

Authenticator Registration and Management#

Registration Process#

Device Registered & Approved
         ↓
Register as Authenticator → Authenticator Profile Created
         ↓
Configure Voting Parameters (quorum, strategy, time limit)
         ↓
Device Begins Receiving Ballots
         ↓
User Responds to Voting Requests
         ↓
Votes Counted According to Strategy

Verified Authenticators#

Only "verified" Authenticators participate in voting. Verification typically occurs through:
Device approval process
Public key registration
Additional verification steps defined by policies

Multiple Authenticators#

Users can register multiple Authenticators:
Each receives ballots for the same poll
Quorum ensures minimum participation
Strategy determines how votes are combined
Provides redundancy if devices are unavailable

Use Cases#

Multi-Factor Authentication#

Scenario: User attempts to login from a new location.
Workflow:
1.
Login policy triggers voting
2.
Ballots sent to user's phone and laptop (both Authenticators)
3.
Strategy: Single approval
4.
User approves on phone
5.
Login proceeds

High-Security Operations#

Scenario: User attempts to delete their account.
Workflow:
1.
Account deletion policy triggers voting
2.
Ballots sent to all registered Authenticators (3 devices)
3.
Strategy: Unanimous
4.
Quorum: 3
5.
All 3 devices must approve within time limit
6.
Account deletion proceeds only if all approve

Transaction Approval#

Scenario: Application initiates a financial transaction on behalf of user.
Workflow:
1.
Transaction policy triggers voting
2.
Ballots sent to user's Authenticators
3.
Strategy: Majority
4.
Quorum: 2
5.
At least 2 devices must respond, majority must approve
6.
Transaction proceeds if majority approves

Automated Approval#

Scenario: Automated system with Authenticator device responding to ballots.
Workflow:
1.
Data upload policy triggers voting
2.
Ballot sent to automated Authenticator
3.
Automated software evaluates ballot criteria
4.
Responds automatically based on predefined rules
5.
Operation proceeds without manual intervention

Voting Configuration Management#

Global Configuration#

Set default voting parameters that apply to all polls unless overridden:
Default quorum size
Default voting strategy
Default time limits
Default maximum attempts

Per-Operation Configuration#

Create specific voting configurations for different operation types:
Login operations use single approval
Account changes use majority
Deletions use unanimous
Financial transactions use threshold

Configuration Hierarchy#

Configurations can be organized hierarchically:
1.
Global defaults: Apply to all operations
2.
Category-specific: Apply to categories of operations (auth, data, admin)
3.
Operation-specific: Apply to individual operation types

Security Considerations#

Authenticators must have registered public keys to receive encrypted ballots
Ballots contain sensitive context - always transmitted encrypted
Voting time limits prevent indefinite operation blocking
Quorum requirements prevent single-device compromise from controlling decisions
Failed votes can trigger security alerts for suspicious activity monitoring
Authenticators can be both manual (user-interactive) and automated (rule-based)
Removing an Authenticator immediately stops it from receiving new ballots
Voting strategies should align with security requirements for each operation type

Authenticator Lifecycle#

Device Approved → Register as Authenticator
         ↓
Configure Voting Parameters (quorum, strategy, limits)
         ↓
Receive RabbitMQ Configuration
         ↓
Listen for Ballots
         ↓
Present Ballot to User or Evaluate Automatically
         ↓
Submit Vote (Yes/No)
         ↓
Poll Resolved According to Strategy
         ↓
Remove Authenticator (optional) → Stop Receiving Ballots

Integration with Storage#

A single device can function as both Storage and Authenticator:
Stores encrypted data (Storage role)
Participates in voting workflows (Authenticator role)
Receives both data and ballots via RabbitMQ
Operates independently in each role
This dual functionality is useful for:
Reducing total device count
Consolidating security functions on trusted devices
Simplifying device management
Modified at 2025-12-25 10:16:00
Previous
Remove storage
Next
Register authenticator
Built with