Difference between revisions of "Wireless Credential Presentation"
(→Context) |
(→Context) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Meme== | ==Meme== | ||
Also called mobile device in-person presentation. | Also called mobile device in-person presentation. | ||
| − | |||
==Context== | ==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. | 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. | ||
| − | |||
| − | |||
===Current Implementations=== | ===Current Implementations=== | ||
| Line 27: | Line 23: | ||
=== Where It’s Headed=== | === 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=== | ===Privacy & Security=== | ||
| − | {| | + | {| border="1",padding="2" |
| − | | Feature | + | | Feature || **BLE** || **NFC |
|- | |- | ||
| − | | **Range** | Up to 10 meters or more—**risk of unintended disclosure** | ~4 cm—**very short range reduces eavesdropping risk** | + | | **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) | + | | **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)=== | ===User Experience (UX)=== | ||
| − | | Feature | **BLE** | **NFC** | + | {| border="1",padding="2", width="777px" |
| − | |- | + | | Feature || **BLE** || **NFC** |
| − | | **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** | + | | **Ease of Use** || Hands-free, works in background—**great for walk-through experiences** || Requires tap—**more deliberate but less seamless** |
| − | | **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) | | + | | **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). | 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 56: | Line 64: | ||
===Design Considerations=== | ===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== | ==References== | ||
[[Category: Verifier]] | [[Category: Verifier]] | ||
Latest revision as of 15:39, 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.
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** | **NFC** |
| **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**.
