Data Protection Impact Assessment (DPIA)
WebAuthn/Passkey Authentication - BlockAuth Package
Document Version: 1.0
Last Updated: 2025-01-01
Status: Approved
Package: auth-pack (BlockAuth)
1. Executive Summary
This DPIA assesses the privacy impact of implementing WebAuthn/FIDO2 passkey authentication using the BlockAuth package.
Conclusion: The implementation is GDPR compliant with LOW privacy risk. No biometric data is processed server-side, eliminating the need for Article 9 special category data protections.
2. Processing Overview
2.1 What is Being Processed
| Data Category |
Server-Side Processing |
Classification |
| Public Keys |
Yes - stored |
Personal Data (Art. 4) |
| Credential IDs |
Yes - stored |
Personal Data (Art. 4) |
| Sign Counters |
Yes - stored |
Technical Metadata |
| AAGUID |
Yes - stored |
Device Type Identifier |
| Fingerprints |
NO |
N/A - Device Only |
| Face Scans |
NO |
N/A - Device Only |
| Biometric Templates |
NO |
N/A - Device Only |
| Private Keys |
NO |
N/A - Device Only |
2.2 Data Flow
┌─────────────────────────────────────────────────────────────────────────┐
│ USER'S DEVICE │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ SECURE ENCLAVE / TEE │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Fingerprint │ │ Face Scan │ │ Private Key │ │ │
│ │ │ Template │ │ Data │ │ (ECDSA) │ │ │
│ │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ │
│ │ │ │ │ │ │
│ │ └──────────────────┴───────────────────┘ │ │
│ │ │ │ │
│ │ Biometric Match? │ │
│ │ Yes/No │ │
│ │ │ │ │
│ │ Sign Challenge │ │
│ │ │ │ │
│ └────────────────────────────┼─────────────────────────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Signature │ ◄─── Only this leaves device │
│ │ + Public Key │ │
│ └────────┬────────┘ │
└───────────────────────────────┼─────────────────────────────────────────┘
│
════════════╪════════════ NETWORK BOUNDARY
│
┌───────────────────────────────▼─────────────────────────────────────────┐
│ APPLICATION SERVERS │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ STORED DATA │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Public Key │ │ Credential │ │ Sign Count │ │ │
│ │ │ (COSE) │ │ ID │ │ Counter │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ NO: Fingerprints, Face Data, Private Keys, Biometric Templates │ │
│ └─────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
2.3 Purpose of Processing
- Authentication: Verify user identity without passwords
- Security: Phishing-resistant, replay-attack resistant authentication
- User Experience: Faster, easier login with biometrics
3. Legal Basis Analysis
3.1 GDPR Article 6 - Lawful Basis for Personal Data
| Basis |
Applicable |
Justification |
| 6(1)(a) Consent |
No |
Not required - other bases apply |
| 6(1)(b) Contract |
Yes |
User needs authentication to use service |
| 6(1)(f) Legitimate Interest |
Yes |
Security of authentication system |
Selected Basis: Contract Performance (6(1)(b)) + Legitimate Interest (6(1)(f))
3.2 GDPR Article 9 - Special Category Data
| Question |
Answer |
| Is biometric data processed? |
NO - only on user's device |
| Is biometric data transmitted? |
NO - only cryptographic proofs |
| Is biometric data stored? |
NO - never reaches servers |
| Does Article 9 apply? |
NO |
Conclusion: Article 9 special category protections do NOT apply because application servers never receive, process, or store biometric data.
4. Risk Assessment
4.1 Privacy Risks Identified
| Risk |
Likelihood |
Impact |
Mitigation |
Residual Risk |
| Biometric data breach |
Impossible |
N/A |
Data never stored |
None |
| Credential ID linkability |
Low |
Low |
IDs are random, per-site |
Low |
| Device fingerprinting via AAGUID |
Low |
Low |
Only identifies device model |
Low |
| Unauthorized credential deletion |
Medium |
Medium |
Requires authentication |
Low |
4.2 Risk Matrix
│ Low Impact │ Med Impact │ High Impact │
───────────┼────────────┼────────────┼─────────────┤
High Prob │ │ │ │
───────────┼────────────┼────────────┼─────────────┤
Med Prob │ │ Cred Del │ │
───────────┼────────────┼────────────┼─────────────┤
Low Prob │ AAGUID │ │ │
───────────┼────────────┼────────────┼─────────────┤
Impossible │ │ │ Bio Breach │
───────────┴────────────┴────────────┴─────────────┘
Overall Risk Level: LOW
5. Data Subject Rights
5.1 Rights Implementation
| Right |
Article |
Implemented |
How |
| Access |
15 |
✅ |
GET /passkey/credentials/ |
| Rectification |
16 |
✅ |
PATCH /passkey/credentials/{id}/ (name) |
| Erasure |
17 |
✅ |
DELETE /passkey/credentials/{id}/ |
| Portability |
20 |
✅ |
GET /passkey/credentials/ returns exportable data |
| Restriction |
18 |
✅ |
Credential can be revoked |
| Object |
21 |
✅ |
User can delete and not use passkeys |
5.2 DSAR (Data Subject Access Request) Support
All passkey data is included in DSAR exports via the credentials list endpoint.
6. Technical & Organizational Measures
6.1 Security Controls
| Control |
Implementation |
| Encryption at rest |
PostgreSQL TDE, credential data encrypted |
| Encryption in transit |
TLS 1.3 required |
| Access control |
JWT authentication required for credential management |
| Rate limiting |
10 req/min for registration, 5 req/min for verification |
| Challenge expiry |
5 minutes (prevents replay attacks) |
| Counter validation |
Detects cloned authenticators |
| Audit logging |
All operations logged via blockauth_logger |
6.2 Privacy by Design Principles
| Principle |
Implementation |
| Data minimization |
Only store necessary cryptographic data |
| Purpose limitation |
Data used only for authentication |
| Storage limitation |
Users can delete credentials anytime |
| Integrity |
Signature verification ensures data integrity |
| Confidentiality |
Private keys never leave device |
7. Third-Party Considerations
7.1 Sub-Processors
| Processor |
Role |
Data Shared |
| Cloud Provider |
Infrastructure |
Encrypted credential data |
| None |
Biometric processing |
No biometric data shared |
7.2 International Transfers
Public keys and credential IDs may be stored in cloud infrastructure. Standard contractual clauses apply. No biometric data is transferred.
8. Consultation Requirements
8.1 Prior Consultation with DPA Required?
NO - Prior consultation with a Data Protection Authority is not required because:
- No high-risk processing of special category data
- Biometric data is not processed server-side
- Risk level is LOW after mitigations
- Processing uses privacy-by-design architecture
9. DPIA Review Schedule
| Review Trigger |
Action |
| Annual review |
Re-assess risks and controls |
| Significant change |
Update DPIA before implementation |
| Security incident |
Immediate review and update |
| Regulatory change |
Review within 30 days |
10. Approval & Sign-Off
| Role |
Name |
Date |
Signature |
| Data Protection Officer |
_______ |
__ |
___ |
| Security Lead |
_______ |
__ |
___ |
| Engineering Lead |
_______ |
__ |
___ |
11. References
12. Appendix: Relevant Code References
| Component |
Location |
| PasskeyCredential Model |
blockauth/passkey/models.py |
| Passkey Service |
blockauth/passkey/services/passkey_service.py |
| Passkey Views |
blockauth/passkey/views.py |
| GDPR Compliance Docs |
blockauth/passkey/README.md |