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 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_Ope nID20Profile.pdf http://www.idmanagement.gov/documents/ICAM_Ope nID20Profile.pdf

4. Authentication Process Attacks/Threats Threat Resistance Requirements Level 1 Level 2 Level 3 Level 4 Session hijacking NoYesYesYes EavesdroppingNoYesYesYes Phishing/pharming(verifier impersonation) NoNoYesYes Man in the middle NoWeakWeakStrong Denial of service/flooding NoNoNoNo

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/privatepersonalidentifi er http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifi er LoA Claims http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3 Card Authentication Username/PasswordX.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/clai ms/privatepersonalidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/clai ms/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: 1. The IdP includes an openid.invalidate_handle indicating that the association has expired. 2. 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. 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 GoogleYahooAOLMySpacePayPalJanRain Orange (France Telecom) Facebook (soon)

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