Concordia telecon 9 Oct 2007
From Project Concordia
(Thanks to JeffH for sending me his meeting notes as well! I welcome corrections on anything below. -Eve)
Contents |
Attendance
Charles Andres, Gerry Beuchelt, Jeff Broberg, Conor Cahill, Scott Cantor, George Fletcher, Adrian Gropper, Jeff Hodges, Eve Maler, Brett McDowell, Eric Tiffany, Bill Washburn
Summary of AIs
- Scott: Share system documentation on issues (re IdP discovery) when using a mixture of protocols.
- Eve: Share product documentation on any issues when using a mixture of protocols. (Others are welcome to do this too!)
- Eve: Gather use-case contributors' input on IdP proxying/gatewaying issues such as message mapping; interest in SAML mapping for CardSpace unmanaged card case; specific use cases for CardSpace usage mixed with SAML. (DONE.)
- Eve: Announce next tentative telecon time on list and check to see if use-case contributors can join then. (DONE.)
- Eve: Create a wiki page to hold our IdP discovery education material.
- Brett: Review wiki and suggest how to highlight eventual Concordia-inspired technical work.
- Bill and Charles: Check on IIW-timeframe options for holding another Concordia workshop (Monday afternoon? Museum meeting room?).
- Eve: Inform Britta of latest IIW workshop discussions. (DONE.)
Summary of potential Concordia deliverables suggested by the discussion
- List of inter-interop scenarios for demonstrating by RSA timeframe (no potential champions yet?)
- WS-Fed/SAML comparison document(s) for education (potential champions: Scott, JeffB)
- Specific CardSpace/SAML use cases that might drive profiling (Eve will query for more data)
- IdP discovery document(s) for education (potential champions: Scott, JeffH, Eve, George)
- WS-Fed/SAML metadata comparison/analysis (no potential champions yet?)
Full notes
We reviewed the items found in the prioritized use cases/other tasks list generated at the DIDW workshop (quoted below throughout), and attempted to identify interested parties (who could become "spec leads"/champions to ensure we make progress).
A-priority
WS-Federation/SAML: - Smart IdP use case (IdP proxying/gatewaying to handle both) - Smart RP use case (protocol-switching at the service provider)
Scott's software supports both protocols today (as do others), and JeffB has interest in working with people on this category. What sorts of problems are deployers having?
- Terminology differences
- Sessions that transcend the protocol used (not a problem?)
- WS-Fed used with SAML V2.0 particularly, because the latter has more features
Do we want to add SAML V1.x/SAML2 as an A-priority set of use cases? This counts as "multi-protocol", after all.
The SAML2 documentation has some info comparing it to SAML V1.x and ID-FF (hmm, can't seem to find links! -- used to be in Tech Overview), but not to WS-Fed. This might be useful, though JeffH cautions that such comparisons get detailed and tricky fast. Comparing particular profiles of SAML to other protocols is relatively concrete and easier. SAML's browser SSO profile is the likeliest target. We wouldn't hold back from pointing out features that appear in one place and not in another, but our description would want to be neutral in general.
Hubert Le Van Gong has done a SAML2/WS-Fed comparison, which we might be able to work from.
Scott is currently working on some system documentation that discusses issues with deploying multiple protocols. Maybe it could be used as input to a more general Concordia document. He'll share it here when he gets a draft done. There are IdP discovery approaches that get more difficult with multiple protocols, which Scott prefers to solve in an RP-centric way. Eve will check with her product folks to see if they have anything similar too.
With an IdP proxying/gatewaying approach as described in our last telecon, a best-practices document might be useful to describe the message mapping that must take place, unless no one's experiencing problems in getting different results from different systems. We should elicit data from use-case contributors about any specific problems or concerns they have here.
Infocards/SAML: - Smart RP use case (how Shib has done things) - Smart(er) client use case (possibly involving the Enhanced Client/Proxy profile, attribute profiles, etc.)
We took this opportunity to discuss how Concordia and OSIS are different/complementary and might be able to work together. (Participants in today's call included some active OSIS members.) OSIS is currently focused mostly on compatibility within the Infocard protocols, with some OpenID mixtures beginning to appear (something not yet highlighted by any Concordia use-case contributors), and its membership is largely vendors (including some who also deploy RPs). Concordia, which has a broader scope, can perhaps document real-life end-to-end scenarios that OSIS might be interested in testing later. Ultimately, there seemed to be agreement that the communities don't overlap in purpose.
Back to Infocards/SAML and its sub-bullets: Scott suggested seeing the goal not as picking particular protocol groupings to improve, but rather to give app developers ways to integrate identity without worrying about having to do any of those jobs themselves. Toolkits and frameworks that bring applications easily into federated environments are needed. If app developers have to pick specific libraries to include in their code, there will be no end to the process. Relying parties are typically on big boxes that can handle a lot of code, so they can get a lot "smarter" before there's performance/size pain.
Eve pushed back a bit. In making life easier for app developers "above", those of us developing identity layers "below" need to be sure that the abstractions we use don't miss any tricks and are available for all low-level implementors to use. We also don't want to promote certain low-level solutions over others. Shib makes these abstractions, as likely do Higgins and quite a few products and maybe even other open-source projects. The abstractions need to be well understood and well documented so that the different identity stacks work the same way repeatably (i.e., they interoperate!).
JeffH noted that these different identity stacks seem to focus on different entities in the federated identity picture -- e.g., client vs. RP.
Eve posed a question to test what sorts of value the Concordia community could provide to the "layer below": What gets exposed, or should get exposed, as the authentication context if someone authenticates by means of CardSpace and then SSOs into a SAML-using environment? CS is phishing-resistant, something the user will likely care about, but today (according to Scott) doesn't provide "strong auth" as far as the RP is concerned. So it may be pointless to have CS-specific authn context information vs. typical IdP-performed strong auth. Is there a need to codify the unmanaged-card case to align it with the SAML equivalent (e.g. bearer token type)? This is another good query area for use-case contributors.
IdP discovery: - Do a survey of how it's done and how painful the current methods are - Collect usability data - Do education and share knowledge about the issue (everyone hates each individual way, but add it all up and you still have to pick a way!)
Scott, Eve, JeffH, and George (for client/RP methods) have an interest in championing this. The goal is to inform people about the options without their getting tired of hearing them and impugning the bearer of bad news. :-)
Logically speaking, there are only so many ways to do discovery. Eve had attempted to outline them in a presentation (slide 18):
– The user tells the RP . By choosing from GUI selections – Assumes an RP-IdP federation (circle of trust or CoT) . Or by directly typing in a location – The RP is configured to know the IdP already . Assumes a CoT again – The client device can tell it . Through a cookie . Or by having extra "smarts" (identity agent) – The client device is the IdP!
Scott added that you can also have lower-level protocols that do a query/response cycle ("home realm discovery" as with SPNEGO at a network level underneath HTTP). Or you can use the WAYF approach, which allows the RP to outsource the problem to another party that asks the user. The SAML common domain cookie approach does this and makes sure the RP stays in control, which means it can work with multiple protocols. We'll collect all this data on the wiki and go from there.
WS-Federation/SAML metadata lessons: - Fill in holes in both directions - Consider how to build in multi-protocol capabilities to each
Scott noted that Shib has a profile of WS-Fed metadata support (but it was more important to get the SAML V1.x metadata profiled just right, as evidenced by the SSTC activity around this).
WS-Federation/SAML metadata distribution and lifecycle: - Consider the in-band and out-of-band ways in which this can be improved - May be impacted by the direction of the dynamic web SSO work
Scott says they're planning to submit a metadata profile to the SSTC around the batch metadata distribution approach they use. It may provide a way forward that applies to SAML and to other technologies.
Interop endpoints - Put a priority on demonstrating interop by RSA conference in April 2008
The question arose on the list and elsewhere: Does this mean the idea of semi-persistent endpoints, or interop events and tests? We think it's only the latter, since only individual endpoint hosts would be responsible for doing the former.
We also want to distinguish heavy interop work (e.g., plugfests and dry runs) vs. public interop demos vs. interop certification (a la the Liberty Interoperable program).
Charles expressed interest in helping to organize this function.
Our goal is to build a firm understanding by November of the "inter-interop" scenarios we'd like to demo at RSA in April.
B-priority
SLO: - Gather ITU-T IdM Focus Group requirements
Rakesh sent out the data on this. We believe the FG has been officially closed.
LOA representations: - Examine them all for opportunities to rationalize across them
Didn't discuss.
CardSpace/ID-WSF bootstrapping
Didn't discuss.
SASL-SAML opportunities: - Consider Jeff's analysis
Didn't discuss.
Keep an eye on
Roaming network access (by IdP proxying?)
Didn't discuss.
Dynamic web SSO profile work: - Vet use cases
We haven't seen input from Patrick yet on the dynamic web SSO stuff.
Attribute schema mapping work
Didn't discuss.
Other
Future meetings
Let's tentatively plan to hold another telecon on Tuesday, Nov 13, 10am-noon PT / 1-3pm ET -- she will check on the list for RSVPs from use-case contributors. By then we want to have a firm idea of what we should interop-demo at RSA in April. Brett reports that a room has been reserved for this activity.
We've got a plan to hold another workshop around the time of IIW, which would nominally be December 3. Some on the call expressed a concern that this wouldn't work because some people would be flying in then. Bill and Charles are on the IIW event design committee and think we should tentatively target Monday afternoon, and will bring that input back to that committee -- and also check on getting one of the Computer History Museum rooms for the time slot. (We will likely also suggest an unconference slot to report on results and gather more data!) Eve will also update Britta Glade on all this.
Wiki care and feeding
Brett would like to see the wiki highlight the areas of technical work that are Concordia-inspired or otherwise relevant. Eve has a little bit of that in the DIDW Workshop 2007 Notes. Brett will look and make additional suggestions.
