Difference between revisions of "Wireless Credential Presentation"

From MgmtWiki
Jump to: navigation, search
(Privacy & Security)
(Context)
Line 51: Line 51:
 
===User Experience (UX)===
 
===User Experience (UX)===
  
| Feature                  | **BLE**                                                                | **NFC**                                                                |
+
{| border="1",padding="2"
|--------------------------|------------------------------------------------------------------------|------------------------------------------------------------------------|
+
| Feature                  || **BLE**                                                                || **NFC**                                                                |-
| **Ease of Use**          | Hands-free, works in background—**great for walk-through experiences** | Requires tap—**more deliberate but less seamless**                     |
+
| **Ease of Use**          || Hands-free, works in background—**great for walk-through experiences** || Requires tap—**more deliberate but less seamless**    
| **Speed**                | Fast once paired, but may require setup                                | Instantaneous with tap—**no pairing needed**                           |
+
|-
| **Battery Impact**      | Low energy, but still active scanning                                  | Minimal—only active during tap                                         |
+
| **Speed**                || Fast once paired, but may require setup                                || Instantaneous with tap—**no pairing needed**  
| **Cross-Platform Support**| Broad, but varies by OS and app permissions                          | Increasingly supported (e.g. Apple Wallet, Android Identity Credential) |
+
|-
 +
| **Battery Impact**      || Low energy, but still active scanning                                  || Minimal—only active during tap  
 +
|-
 +
| **Cross-Platform Support**|| Broad, but varies by OS and app permissions                          || Increasingly supported (e.g. Apple Wallet, Android Identity Credential)
 +
|-
 +
|}
  
 
BLE is ideal for **continuous or ambient interactions** (e.g. walk-through gates), while NFC excels in **explicit, high-trust exchanges** (e.g. ID checks at TSA).
 
BLE is ideal for **continuous or ambient interactions** (e.g. walk-through gates), while NFC excels in **explicit, high-trust exchanges** (e.g. ID checks at TSA).
Line 62: Line 67:
 
===Design Considerations===
 
===Design Considerations===
  
- **BLE** is better for **hands-free, high-throughput environments** like stadiums or transit.
+
*BLE** is better for **hands-free, high-throughput environments** like stadiums or transit.
- **NFC** is better for **high-assurance, user-mediated interactions** like border control or age verification.
+
*NFC** is better for **high-assurance, user-mediated interactions** like border control or age verification.
- Both can support **ISO 18013-5** and **W3C Verifiable Credentials**, but NFC tends to align more naturally with **user consent and minimal disclosure**.
+
Both can support **ISO 18013-5** and **W3C Verifiable Credentials**, but NFC tends to align more naturally with **user consent and minimal disclosure**.
  
 
==References==
 
==References==
  
 
[[Category: Verifier]]
 
[[Category: Verifier]]

Revision as of 15:36, 17 July 2025

Meme

Also called mobile device in-person presentation.


Context

Wireless Credential Presentation is an emerging capability that allows users to present digital credentials—such as mobile driver’s licenses (mDLs), verifiable credentials, or digital IDs—**over proximity-based wireless channels** like Bluetooth Low Energy (BLE), Near Field Communication (NFC), or Wi-Fi Aware. It’s a key component of mobile identity systems and digital wallets, especially in contexts like airport security, age verification, or access control.

Here’s a snapshot of where things stand:

Current Implementations

- **ISO/IEC 18013-5**: Defines how mobile driver’s licenses can be presented wirelessly using BLE or NFC. Adopted by Apple and Google in their wallet ecosystems. - **Android Identity Credential API**: Supports secure wireless presentation of credentials using hardware-backed storage and reader authentication. - **Apple Wallet**: Supports mDLs and TSA checkpoints using NFC or BLE, with user consent and Face ID/Touch ID gating the release of data.

Security and Privacy Features

- **User consent**: Presentation is gated by biometric or PIN confirmation. - **Selective disclosure**: Only the requested attributes (e.g., age, name) are shared—not the full credential. - **Reader authentication**: The verifier must prove its identity before receiving data. - **Session encryption**: Wireless channels are encrypted to prevent eavesdropping or replay attacks.

Challenges and Open Questions

- **Interoperability**: Different platforms (e.g., Android vs. iOS) and jurisdictions may implement standards differently. - **Trust frameworks**: Who certifies the verifier? How is revocation handled? - **Offline support**: Wireless presentation must work without internet access, which complicates revocation and freshness checks. - **User transparency**: Ensuring users understand what’s being shared and with whom.

Where It’s Headed

  • eIDAS 2.0** in the EU and **NSTIC-aligned** efforts in the U.S. are pushing for standardized, cross-border digital identity systems.
  • OpenID4VP** and **DIDComm** are being explored as protocols for secure, privacy-preserving credential exchange.
  • Wallet interoperability** and **cross-platform reader support** are active areas of development.

the technical and experiential differences between **BLE (Bluetooth Low Energy)** and **NFC (Near Field Communication)** for wireless credential presentation—especially in terms of **privacy**, **user experience (UX)**, and **security**.

Privacy & Security

Feature **BLE** **NFC
**Range** Up to 10 meters or more—**risk of unintended disclosure** ~4 cm—**very short range reduces eavesdropping risk**
**User Awareness** May trigger without user noticing (passive scanning) Requires deliberate tap—**user is always aware**
**Reader Authentication** Often supported via session keys or certificates Strong mutual authentication possible (e.g. ISO 18013-5)
**Data Minimization** Depends on implementation; risk of over-sharing Easier to enforce **selective disclosure**

NFC’s short range makes it inherently more privacy-preserving, while BLE’s convenience comes with a need for **stronger software safeguards**.

User Experience (UX)

Feature **BLE** - **Ease of Use** Hands-free, works in background—**great for walk-through experiences** Requires tap—**more deliberate but less seamless**
**Speed** Fast once paired, but may require setup Instantaneous with tap—**no pairing needed**
**Battery Impact** Low energy, but still active scanning Minimal—only active during tap
**Cross-Platform Support** Broad, but varies by OS and app permissions Increasingly supported (e.g. Apple Wallet, Android Identity Credential)

BLE is ideal for **continuous or ambient interactions** (e.g. walk-through gates), while NFC excels in **explicit, high-trust exchanges** (e.g. ID checks at TSA).

Design Considerations

  • BLE** is better for **hands-free, high-throughput environments** like stadiums or transit.
  • NFC** is better for **high-assurance, user-mediated interactions** like border control or age verification.

Both can support **ISO 18013-5** and **W3C Verifiable Credentials**, but NFC tends to align more naturally with **user consent and minimal disclosure**.

References