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 QuorumVoting Participants
1 Alam, Mohammad, Fraunhofer SIT joined as of February 18, 2010
07:50 2 Clement, Philippe, France Telecom joined as of July 30, 2009 12:02
3 Davis, Peter, NeuStar joined as of June 2, 2009 11:48 4 Gourmelen, Gael, France Telecom / Orange joined as of August 18,
2009 14:14 5 Kellomaki, Sampo, joined as of March 2, 2010 16:28 6 Rerup, Neil joined as of Oct. 31, 2009 15:13 7 Salzberg, Ken, Intel joined as of June 30, 2009 12:02 8 Sunday, Bob, Government joined of Canada as of October 23, 2009
6:25
Rollcall and QuorumNon-Voting Participants 1 Adachi, Shin, NTT joined as of July 3, 2009
01:41 2 Adams, Trent, Internet Society joined as of
February 24, 2010 08:06 3 Ar Foll, Fulup, Sun Microsystems joined as of
September 16 2009 11:00 4 Bailleux, Benoit, France Telecom joined as of
November 17, 2009 11:54 5 Baker, Richard joined as of September 8,
2009 12:14 6 Barbir, Abbie joined as of Dec. 24, 2009 06:17
7 Broser, Christian, SPIKE joined as of July 16,
2009 12:14 8 Cantor, Scott, Internet2 joined as of June 30,
2009, 10:44 9 Dagg, Kenneth, Government of Canada joined
as of Feb. 24, 2010 05:20 10 Ganem, Herve joined as of September 16,
2009 11:00
Non-Voting Participants 11 Hardjono, Thomas joined as of June 24,
2009 09:35 12 Kannappan, Lena, FuGen Solutions, Inc.
joined as of September 16, 2009 11:00 13 Lopez, Diego, RedIRIS joined as of June 23,
2009 16:32 14 Lynch, Lucy, Internet Society joined as of
September 16, 2009 11:00 15 Schwartz, Michael, Gluu joined as of June
24, 2009 01:24 16 Shelley, Robert, N-Link Corporation joined as
of June 24, 2009 12:17 17 Solberg, Andreas, UNINETT joined as of July
9, 2009 22:09 18 Soutar, Colin, CSC joined as of March 5,
2010 11:24 19 Tesson, Olivier joined as of June 24, 2009
04:13 20 Trilli, Kevin, TRUSTe joined as of September
23, 2009 21:27 21 Wallis, Colin, Dept of Internal Affairs, NZ
Government joined as of September 16, 2009 11: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
IDPISA
RP
IDP Selection Delegation
Some metadata only *
Metadata exchange & Authenticationdelegation
* e.g. for the IDP capabilities discovery
ISA as a facilitator 1/3
ISA
RelyingParty
IdentityProvider
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 & Authenticationdelegation
Metadata exchange & Authenticationdelegation
RP IDP
ISA as an IDP proxy 2/3
IdentityProvider
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
Userdatabase
ISA
RelyingParty
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
IDPISA
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
IdentityProvider
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.
RelyingParty
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 p
lenary
First d
raft fo
r "Tec
hnica
l
way to
integ
rate t
he IS
A"
First d
raft fo
r "meta
data
spec
s evo
lution
"
GUI and
UX gu
idelin
es
ISA im
plemen
tation
guide
lines
July
Octobe
r
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 <OrganizationDisplayName> for
DisplayName
Use of <OrganizationURL> for LogoQuestion : What is the actual status of that proposal ?
IDP "Display" metadata 2/3
OpenID :Proposal : Extension to the YADIS XRDS document.
<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"><XRD><Service priority="0">
<Type>http://specs.openid.net/auth/2.0/signon</Type> <URI>http://www.myopenid.com/server</URI></Service></XRD></xrds:XRDS>
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="http://www.w3.org/2000/09/xmldsig#"entityID="https://IdentityProvider.example.com/SAML"> <Extensions><attr:EntityAttributes><saml:AttributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"><saml:AttributeValue>http://foo.example.com/assurance/loa1</saml:AttributeValue></saml:Attribute></attr:EntityAttributes></Extensions>...</EntityDescriptor>
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 ?)
<xrd> <Service> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://schemas.openid.net/pape/policies/...</Type> <URI>https://example.com/server</URI> </Service></xrd> 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-1icam-assurance-level-2icam-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="http://www.w3.org/2000/09/xmldsig#"entityID="https://IdentityProvider.com/SAML"><ds:Signature>...</ds:Signature> <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" />...
</IDPSSODescriptor></EntityDescriptor>
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.<xrd> <Service> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/srv/ax/1.0</Type> <URI>https://example.com/server</URI> </Service></xrd>
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)
Microsoft Word Document