IdP Selection WG Hillsboro, March 10th Version v0

Agenda Rollcall, Quorum Proposed models First achievements for Hillsboro plenary Charter Proposal for a unified WG (IDPS + ULX)

Rollcall and quorum

Rollcall and Quorum Voting Participants 1 Alam, Mohammad, Fraunhofer SIT joined as of February 18, :50 2 Clement, Philippe, France Telecom joined as of July 30, :02 3 Davis, Peter, NeuStar joined as of June 2, :48 4 Gourmelen, Gael, France Telecom / Orange joined as of August 18, :14 5 Kellomaki, Sampo, joined as of March 2, :28 6 Rerup, Neil joined as of Oct. 31, :13 7 Salzberg, Ken, Intel joined as of June 30, :02 8 Sunday, Bob, Government joined of Canada as of October 23, :25

Rollcall and Quorum Non-Voting Participants 1 Adachi, Shin, NTT joined as of July 3, :41 2 Adams, Trent, Internet Society joined as of February 24, :06 3 Ar Foll, Fulup, Sun Microsystems joined as of September :00 4 Bailleux, Benoit, France Telecom joined as of November 17, :54 5 Baker, Richard joined as of September 8, :14 6 Barbir, Abbie joined as of Dec. 24, :17 7 Broser, Christian, SPIKE joined as of July 16, :14 8 Cantor, Scott, Internet2 joined as of June 30, 2009, 10:44 9 Dagg, Kenneth, Government of Canada joined as of Feb. 24, :20 10 Ganem, Herve joined as of September 16, :00 Non-Voting Participants 11 Hardjono, Thomas joined as of June 24, :35 12 Kannappan, Lena, FuGen Solutions, Inc. joined as of September 16, :00 13 Lopez, Diego, RedIRIS joined as of June 23, :32 14 Lynch, Lucy, Internet Society joined as of September 16, :00 15 Schwartz, Michael, Gluu joined as of June 24, :24 16 Shelley, Robert, N-Link Corporation joined as of June 24, :17 17 Solberg, Andreas, UNINETT joined as of July 9, :09 18 Soutar, Colin, CSC joined as of March 5, :24 19 Tesson, Olivier joined as of June 24, :13 20 Trilli, Kevin, TRUSTe joined as of September 23, :27 21 Wallis, Colin, Dept of Internal Affairs, NZ Government joined as of September 16, :00

Proposed Models

Identified requirements  Input requirements identified in the IDP Selection MRD can be divided into 4 main categories :  Possibility for the SP to delegate the selection of the user's IDP to an ISA and express some criteria to be considered for that selection process.  Discovery of the user's preferred IDP(s) by ISAs.  Possibility for the ISA to obtain user's IDP(s) capabilities as well as other data (metadata).  GUI and UX guidelines for SP and ISA.

Envisioned next step 1/2  Delegate to the ISA –Extract from MRD all needed claims, both by IdP and by RP –Technical way to integrate the ISA on SP side using RP metadata (aim : same metadata for both ISA in the browser and in the network)  Discovery of the user's preferred IDP –Mainly internal to the ISA (to be assessed based on MRD) : should be described into an "ISA implementation guidelines" document (common guidelines for both ISA in the browser and in the network ?).

Envisioned next step 2/2  IDP's capabilities –Lacks in existing IdP metadata specifications already identified in the "Gap analysis" document : requires evolutions on these specifications. –E.g. Supported authentication context by IDP Logo and display name for each IDP …  GUI and UX guidelines for SP and ISA. –Common guidelines for both ISA in the browser and in the network.

Pending point to be discussed: which strategy ? 3 possible models for an ISA in the network a.The ISA as a facilitator : just allows the user to choose the IDP and everything else is done directly between RP and IDP b.The ISA as an IDP proxy, as defined in the Liberty/SAML specifications c.the ISA acts on behalf of the SP and just convert flows from a protocol to an other if needed

ISA as a facilitator 1/3  Functional view IDP ISA RP IDP Selection Delegation Some metadata only * Metadata exchange & Authentication delegation * e.g. for the IDP capabilities discovery

ISA as a facilitator 1/3 ISA Relying Party Identity Provider     ISA used only during the IDP choice  The ISA is not aware of the rest of the transaction  The RP must implement all protocols corresponding to the various IDP Note : numbers  to  represent the order of the interactions.  Technical view

ISA as an IDP proxy 2/3  Functional view IDP ISA RP Metadata exchange & IDP Selection & Authentication delegation Metadata exchange & Authentication delegation RPIDP

ISA as an IDP proxy 2/3 Identity Provider      Protocol on link  and  can be any widely spread protocol.  As a proxy, the ISA must implement fully the chosen protocol(s) for links  and .  Possibly single protocol between ISA and RP  IDP doesn't have knowledge of the RP and vice versa.  In case of ISA failure, users can't access the RP anymore (or with complex failover mecanism)  Users must exist in the ISA database (needs provisioning)  Might be a problem for the RP to access to IDP APIs User database ISA Relying Party   Note : depending on the protocol, links , ,  and  may or may not go through the browser. Note : numbers  to  represent the order of the interactions.  Technical view

ISA acts on behalf of the SP 3/3  Functional view IDP ISA RP IDP Selection & Authentication delegation (acting on behalf of the real RP) Authentication delegation RP Remote RP endpoints metadata

ISA acts on behalf of the SP 3/3 ISA Identity Provider      Protocol on links  and  can be any widely spread protocol.  As an intermediary, the ISA must implement fully the chosen protocol(s) for links  and .  Single protocol between ISA and RP  Opportunity to specify a simplified SSO profile of existing specs for steps  and   In case of ISA failure, SP can use another one or no ISA. Relying Party   Note : depending on the protocol, links , ,  and  may or may not go through the browser. Note : numbers  to  represent the order of the interactions.  Technical view

First achievements for Hillsboro plenary

Roadmap proposal March plenary First draft for "Technical way to integrate the ISA" First draft for "metadata specs evolution" GUI and UX guidelines ISA implementation guidelines July October

Status on IDP's metadata requirements and proposals to fulfill these requirements IDP Selection WG

IDP "Display" metadata 1/3 SAML : Sampo's proposal "Profile for Use of DisplayName" already covers the requirements : Use of for DisplayName Use of for Logo Question : What is the actual status of that proposal ?

IDP "Display" metadata 2/3 OpenID : Proposal : Extension to the YADIS XRDS document. <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"> Proposal : Advertize OP's DisplayName and Logo URL part of XRDS document published by the OP ? Help needed on best way to do it with XRDS…

IDP "Display" metadata 3/3 InfoCard : N/A (either just the "InfoCard" logo or CardTile of the last used InfoCard)

IDP's supported ACs and ALs 1/3 SAML : Generic mechanism defined in "SAML Metadata Extension for Entity Attributes" and specific attribute already defined in "SAML Identity Assurance Profiles" <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:attr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:ds=" entityID=" <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> Proposal for ACs : define a new attribute name for Authentication Context classes : urn:oasis:names:tc:SAML:attribute:authn- context-class

IDP's supported ACs and ALs 2/3 OpenID : Supported Authentication policies can already be advertized in the Yadis XRDS document as specified in "OpenID Provider Authentication Policy Extension 1.0" (should also be used to advertize supported Assurance Level ?) Can it be used as well to advertize the OP's Assurance Level ? (and how does it relates to the OIX Listing Service ?)

IDP's supported ACs and ALs 3/3 InfoCard : Authentication Contexts and Assurance Levels are just considered as claims. As an example, claims for Assurance Levels have been defined by ICF : icam-assurance-level-1 icam-assurance-level-2 icam-assurance-level-3

IDP's supported attributes/claims 1/3 SAML : Already defined in SAML Metadata specifications : <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds=" entityID=" <IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">... <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:saml_attribute_name_1" /> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:saml_attribute_name_2" />...

IDP's supported attributes/claims 2/3 OpenID : The Yadis XRDS document only advertizes the SREG/AX service(s) supported by the OP but not the exact list of supported attributes/claims. Proposal : Extension to the YADIS XRDS document Proposal : Explicitly advertize OP's supported attributes/claims part of XRDS document published by the OP ? Help needed on best way to do it with XRDS…

IDP's supported attributes/claims 3/3 InfoCard : Supported claims are advertized at the creation/import of the Information Card.

More thoughts required… How to advertize the list of APIs an IDP/OP can provide bootstrap for ?

Summary of required evolutions for IDP's metadata SAML : Adoption of Sampo's proposal for DisplayName/Logo New attribute name required to advertize supported ACs classes (already done for Assurance Levels) OpenID : Yadis XRDS document extension for both DisplayName/Logo and supported attributes/claims ? InfoCard : Generic claim mechanism already existing

Technical Way to Integrate the ISA

Charter Proposal for a unified WG (IDPS + ULX)

Thank you