Re-using existing PKIs for online Identity Management
•Download as PPT, PDF•
0 likes•514 views
The document discusses using existing public key infrastructure (PKI) from electronic passports to enable online identity management according to Identity 2.0 standards. It describes how an Identity Provider could verify a user's passport remotely by performing authentication and accessing standardized data groups. Attributes from the passport like date of birth could then be translated to be more privacy-friendly before being shared with a Relying Party. Combining offline and online identity management allows flexibility in privacy protection while leveraging widespread government PKI systems.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (8)
Similar to Re-using existing PKIs for online Identity Management
Similar to Re-using existing PKIs for online Identity Management (20)
Recently uploaded
Recently uploaded (20)
Re-using existing PKIs for online Identity Management
- 1. Re-using existing PKIs for online Identity Management Martijn Oostdijk Novay 22/10/09 | Session ID: 305 Classification: Intermediate
- 2. Agenda Electronic Passports A short introduction to Identity 2.0 Using the ePassport PKI for online IdM Conclusions
- 4. An Introduction to Identity 2.0
- 7. Identity Management Would like to use service Facilitates this process by - checking credentials of C - controlled release of attributes about C Client (C) Relying Party (RP) Identity Provider (IdP)
- 14. e Passport Chip Logo MRZ Antenna
- 15. Logical Data Structure hashes DGs + signature issuing state SOd public key for Active Authentication DG15 [some people with really long names] [ DG11 ] photo face DG2 name, etc, a.o. date of birth and BSN DG1 index of DGs present COM
- 18. Using the ePassport PKI for online IdM
- 20. Information Card protocol 1. Access 2. Policy 3. Filter cards 4. Select card 5. Request token 6. Give token 7. Give token 5/6. BAC + AA + DG1 + DG15 + SOd IdP Client RP User
- 22. Conclusions
- 24. Questions?
Editor's Notes
- 14.45
- This is the “apply” slide.
- 14.50
- Identity is necessary (a driver) for online services. Today’s Internet user no longer uses nick names, but publishes identity information on social network or blog. Users expect to be in control over who gets what attributes, though.
- Checking credentials of C requires RP to trust IdP Controlled release of attributes about C’s identity requires C to trust IdP
- To counter last drawback: implement identifier with a tamper-proof token (smart card). Example of Online IdP: InfoCard, Example of offline IdP: ePassport.
- User-centric as opposed to IdP-centric OpenID and InfoCard different communities / cultures. Technically browser vs. dedicated client. Dedicated client offers more flexibility. OpenID seems to have more support both in terms of number of IdPs and number of RPs.
- MS learned from MS passport.
- Managed cards: not just attributes kept at IdP. Both client and IdP need to be online for transaction.
- 15.10
- BAC: “basic” because access key is based on date-of-birth, date-of-expiry, document number. EAC: issuing country limits access to its citizen’s biometric data by issuing certificates to trusted countries.
- Google alert found root certificates for 12 countries: Austria, Czech Republic, Finland, France, Germany, Greece, Hungary, Monaco, Netherlands, Slovenia, Spain, Switzerland.
- 15.20
- IdP translates DoB to “over 18” to be sent to RP.
- The red stuff is what we added.
- EAC: most ePassport issuing countries keep basic card holder data in DG1 (only protected by BAC) User needs to trust IdP with respect to privacy RP needs to trust IdP with respect to attribute translation (doesn’t get to see signed DG)
- 15.30
- Different role of IdP: Attributes not stored at IdP but in token of user Possibility for privacy protection by translating “raw” attributes Would ideal: privacy protection in ePassport, while still be able to send “signed” attributes to RP
- 15.35