openID & Information Card Profiles for ICAM

1. openID & Information Card Profiles for ICAM • John Bradley • jbradley@mac.com • http://thread-safe.net • http://test-id.org

2. Information Card (IMI) • IMI 1.0 is an OASIS Standard • Profile of WS-Federation • Requires a browser extension • Profile for LoA 1 - 3 • http://www.idmanagement.gov/documents/ICAM_IMI_10_Profile.pdf

3. openID • openID 2.0 is a openID Foindation (OIDF) spec • openID discovery XRDS is a OASIS XRI-TC spec • Profile for LoA 1 • http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

5. Out of Scope • Verification of assertion attributes

6. IMI Profile • Token type • SAML 1.1 (SAML 2.0 and Zero Knowledge will be added later) • IdP issued tokens only. (Self issued p-card tokens will be a separate profile) • Audience Restriction • RP must be a SSL protected endpoint • The SAML token is audience restricted and encrypted with the public key of the RP by the issuer.

7. Private Personal Identifier • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • LoA Claims • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3 • Card Authentication • Username/Password • X.509 • Personal Card • Kerberos token

8. OpenID Profile mitigations • Assertion reuse • Assertions include a timestamp and a nonce which is checked by the RP. The RP keeps track of assertions that were consumed • Assertion manufacture/modification • IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the IdP via a HMAC shared secret. • Assertion redirect • The signed assertion includes the identity (return_to) of the RP for whom it was generated, and the RP verifies it.

9. Identifiers • Must be Pair-wise Pseudonymous by RP • The pseudonym is used to identify the user to the RP in a way that protects the user's privacy by preventing correlation among RPs. The RP is identified by its realm. • Must use Directed identity.

10. Associations • Must be over SSL • Should be HMAC-SHA256 • The IdP shall expire associations older than 24h • The IdP shall not reuse associations between RPs • The RP must key association handles by IdP

11. OpenID Provider Authentication Policy (PAPE) • Authentication Policies • Used by RPs to request aspects of a profile • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • Maximum Authentication Age • Used to guarantee a fresh interactive login.

12. Relying Party Discovery • The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [OpenID 2.0] Section 13. • The XRDS MUST be published at the URL matching the realm. • The URI for the XRDS document that is discovered via Yadis MUST have an https: scheme. • The IdP MUST perform RP discovery and return_to validation per [OpenID 2.0] Section 9.2.1. • If return_to validation fails, the IdP MUST return an error, or the IdP MAY present an error message and discontinue the OpenID authentication process.

13. Assertion Verification • The RP MUST verify that all of the following fields (without the "openid." prefix prepended) are included in the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. • All OpenID extensions MUST be signed by the IdP. • The RP MUST check the openid.response_nonce to make sure that an assertion from the IdP with this nonce has not already been used. • It is RECOMMENDED that the RP set a restriction on the amount of elapsed time from the timestamp in the nonce until receipt. • The RP MUST check the return_to value in the assertion to verify that the assertion was produced for the RP.

14. Assertion Verification • The openid.identity and openid.claimed_id MUST be the same with the exception of a fragment that may be appended to the openid.claimed_id. • The RP MAY use "Direct Verification" to validate the assertion when: • The IdP includes an openid.invalidate_handle indicating that the association has expired. • The IdP sends an unsolicited assertion

15. Security Considerations • TLS/SSLv3 MUST be used at all endpoints, discovery redirects, and the URI of the XRDS document. • The RP SHOULD negotiate a cipher suite that includes either Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) during the SSL/TSL handshake. • NIST encourages use of the faster and stronger AES algorithm. • The RP MUST verify that the IdP is authorized LOA 1 IdP through verification of URL endpoints and server certificates during discovery and Direct Communication (see [OpenID 2.0] Section 5.1). • During Direct Communication, the RP MUST check the revocation status of the IdP server certificate.

16. Security Considerations • The RP and IdP SHOULD employ frame busting techniques to avoid possible eavesdropping by a third-party web site, and cross site request forgery. • The RP MUST reject any assertion where openid.ns is other than http://specs.openid.net/auth/2.0.

17. Questions? jbradley@mac.com

18. openID history • May 2005 invented by Brad Fitzpatric at SixApart (LiveJournal) • Oct 2005 XRDS • March 2006 Simple Registration 1.0 (JainRain) • May 2006 openID 1.1 • Dec 2007 openID 2.0 and Atribute Exchange 1.0

19. openID Providers • Google • Yahoo • AOL • MySpace • PayPal • JanRain • Orange (France Telecom) • Facebook (soon)

20. openID Relying Partys • FaceBook • MapQuest (AOL) • Plaxo • Blogger (Google) • TypePad (Six Apart)