Dynamic Federation

Convener

Bob Morgan

Attendees

Shin Adachi - AdachiUS
Les Chasen - Neustar/XRI
Brian Wormington - CloakX
Gerald Beuchelt - Sun
Pat Patterson - Sun
Mike Beach - Boeing
Paul Madsen - ATT
Gerry Gebel - Burton Group
Victor Leong - Sun
Greg Blana - Boeing
Brett McDowell - Liberty Alliance
Steve Land - StrongEye Solutions
Jens Haeusser - UBC
Andrew Nash - PayPal
Rajesh Pandey - eTouch

Notes

Attendance: 15 or so

SAML-based federations have challenges scaling: IdP discovery, metadata discovery, protocol binding choice, trust establishment, key management, attribute and nameID usage

Many of these concerns apply in other technologies too, eg Infocard

Can we replicate the scalability of OpenID? Or at least as much of it as required by the SAML-interested community

PingID proposal re: dynamic federation: Dynamic Federation Under the Covers

How can we simplify IdP discovery?

Metadata and trust problems: getting metadata is one thing, deciding it is trustworthy is another

User shows up at RP, types in email, RP makes decision to dynamically federate?

Can you do ad-hoc without contracts?

Do we need to cover all OpenID use cases, or just a subset for success?

Not full scale ad-hoc; more ease of deployment

Can we avoid "email exchange of all the goo"

Shibboleth- reliance on SAML metadata

publish separately at each site
peer entity key directly in metadata, use that key directly for SAML assertion validation

How deep into PKI do we need to go?

for metadata exchange, some as needed
for SAML protocol, none

Where is this going- submission to OASIS TC; profile with x features

incorporate some of SAML core spec into one document?

If you don't follow the trust chain, how do you prevent spoofing?

How do you trust what is in the metadata?

Sign metadata by trust vendor (ie verisign) or assessor

Separate run-time concerns

What is trust- different levels

LOA concerns: a site may not be able to self-assert all its site data, eg the level of assurance it has been certified to operate at

Still a role for federation operator to certify metadata

Can IdP Metada signing be done during transaction by third party?

Trusted reputation broker could either sign before, or during transaction

Must have revocation lists; how often do you check? Caching?

SAML allows pseudonimity, and can help prevent collusion- how does this operate in this space? Does use of email for IdP discovery make other privacy protection moot?

Should the discovery element be separable from the rest of the dynamic federation processes?

Trusting 3rd party identity providers is hard.

How do we make this understandable by the average consumer?

Should privacy be enabled through best practice (throw away data used for discovery after discovery), or should it be baked in?

SP should set an IdP specific cookie to simplify returning use.

France Telecom starting effort in Liberty Alliance to standardize IdP discovery- want an industry standard; this should be synced with DF effort

What about attributes? Should the profile say: no attributes? or "can send, but no guarantee of handling at SP"? or "must accept and understand"?

Are we simply allowing easier IdP discovery, or synchronizing account linkage once discovered?

Starting point: IdP and SP don't know each other. Implies no existing accounts to link to

What is the persistent identifier? Email? Persistent ID? Pick one of these 3?

XRI as alternative discovery mechanism- same challenge as DDNS (lack of deployment)?

Reuse iname infrastructure? Simple profile for SAML endpoints?

Rather than retrieving SAML metadata, retrieve XRDS file? Permits SP to be multi-protocol

Should you chain the metadata docs, or fall back from XRDS to SAML metadata if no XRDS found?

Probably will need to have multiple ways to find things.

Discussion will move to OASIS SSTC list "soon"

Dynamic Federation

Contents