Difference between revisions of "Wireless Credential Presentation"
(Created page with "==Meme== Also called mobile device in-person presentation. ==Context== Wireless Credential Presentation is an emerging capability that allows users to present digital crede...") |
(→Context) |
||
| Line 9: | Line 9: | ||
Here’s a snapshot of where things stand: | 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. | - **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. | - **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. | - **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. | - **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. | - **Selective disclosure**: Only the requested attributes (e.g., age, name) are shared—not the full credential. | ||
| Line 24: | Line 20: | ||
- **Session encryption**: Wireless channels are encrypted to prevent eavesdropping or replay attacks. | - **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. | - **Interoperability**: Different platforms (e.g., Android vs. iOS) and jurisdictions may implement standards differently. | ||
- **Trust frameworks**: Who certifies the verifier? How is revocation handled? | - **Trust frameworks**: Who certifies the verifier? How is revocation handled? | ||
| Line 32: | Line 26: | ||
- **User transparency**: Ensuring users understand what’s being shared and with whom. | - **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. | - **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. | - **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. | - **Wallet interoperability** and **cross-platform reader support** are active areas of development. | ||
| − | + | Let’s unpack 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** | + | {| line=1,space=2 |
| − | |- | + | | 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** | | + | | **Range** | Up to 10 meters or more—**risk of unintended disclosure** | ~4 cm—**very short range reduces eavesdropping risk** |= |
| − | | **Reader Authentication**| Often supported via session keys or certificates | Strong mutual authentication possible (e.g. ISO 18013-5) | | + | | **User Awareness** | May trigger without user noticing (passive scanning) | Requires deliberate tap—**user is always aware** |= |
| − | | **Data Minimization** | Depends on implementation; risk of over-sharing | Easier to enforce **selective disclosure** | | + | | **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**. | 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** | **NFC** | | | Feature | **BLE** | **NFC** | | ||
| Line 71: | Line 54: | ||
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). | ||
| − | + | ===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. | ||
| Line 79: | Line 60: | ||
- 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:22, 17 July 2025
Contents
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.
Let’s unpack 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
| **BLE** | **NFC** | ||||
| Up to 10 meters or more—**risk of unintended disclosure** | ~4 cm—**very short range reduces eavesdropping risk** |= | May trigger without user noticing (passive scanning) | Requires deliberate tap—**user is always aware** |= | Often supported via session keys or certificates | Strong mutual authentication possible (e.g. ISO 18013-5) |= | 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) |
**BLE** | **NFC** | |
| Hands-free, works in background—**great for walk-through experiences** | Requires tap—**more deliberate but less seamless** | | Fast once paired, but may require setup | Instantaneous with tap—**no pairing needed** | | Low energy, but still active scanning | Minimal—only active during tap | | 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 |
