Meeting Minutes from 3 December 2007 Workshop

From Project Concordia

Jump to: navigation, search

Contents

Attending

Andy Dale (OOTAO), Drummond Reed (Parity & Cordance & OASIS XRI TC), Mike Beach (Boeing), Joe Steele (Adobe), Jim Pravetz (Adobe), Casper Biering (Netamia), Henrik Biering (Netamia), Tasuki Sakushima (NRI), Dean Landsman (LCG), George Fletcher (AOL), Les Chasen (Neustar), Rich Conlan (Google), Lena Kannappan (FuGen Solutions), Greg Blana (Boeing), Doc Searls (IIW), Marty Schleiff (Boeing), Pamela Dingle (Nulli Secundey; Pamela Project), Conor Cahill (Intel), Shin Adachi (NTT), Paul Madsen (NTT), Pat Patterson (Sun), John Bradley (OOTAO), Uppili Srinivasan (Oracle), Charles Andres (Parity), Hank Mauldin (Cisco), Abbie Barbir (Nortel), Paul Trevithick (Parity), Mike Jones (Microsoft), Britta Glade (Liberty Alliance), Brett McDowell (Liberty Alliance)

Agenda Setting

Mike Jones chaired the meeting. Brett McDowell took the minutes.

After some discussion it was agreed that the agenda would consist of two primary topics:

  • Discuss and resolve the questions raised recently about the relationship between OSIS and Concordia.
  • Discuss and define the use cases that will be exercised in the Interoperability Scenarios for the Concordia Interop planned for the RSA Security Conference in April, 2008. Along with defining the scenarios we will collect commitment from participants.

Action items

  • [Details to be supplied shortly]

The relationship between OSIS and Concordia

  • To summarize the background, Tony Nadalin (IBM) had asked some questions to the concordia community list about the relationship between OSIS and Concordia to see if there was any duplication of effort.
  • Conor Cahill pointed out in the discussion that the one-page summaries submitted to IIW for both OSIS and Concordia seemed very similar.
  • AGREED: OSIS and Concordia started working on interoperability issues from different points of reference, namely:
    • OSIS started its work to enable interoperability between open source Identity Selector implementations and Cardspace.
    • Concordia started its work to enable interoperability of specific deployer use cases that require interoperability across WS*, SAML, Liberty and OpenID protocols.
  • AGREED: OSIS and Concordia have both evolved to the point where there is some overlap but it is not 100% overlap in how you might describe the purpose of each effort (i.e. Concordia now names Cardspace interoperability in some of the use cases) but there still isn't direct overlap with actual work going on in each project. The interoperability scenarios being worked on for the OSIS demo are distinct from those being worked on for the Concordia demo.
  • AGREED: Mike Jones and others who participate in both efforts will continue to pay close attention to coordination to avoid direct overlap and leverage opportunities to collaborate where possible.
  • AGREED: We must avoid scheduling OSIS and Concordia sessions at the same time. This includes face-to-face and teleconference scheduling conflicts.
  • CONCLUSION: We will keep the informal coordination in place to avoid duplication and that should be sufficient at this point (seems to have worked so far). Perhaps some day down the road the two initiatives may want to come together in a more formal way.

The interoperability scenarios to demonstrate at RSA in April

Mike J. facilitated the session by first reviewing all of the current use cases we have captured as candidates for the interoperability demonstration.

Review of Existing Use Cases:

  • Scenario #1 (from Eve's notes from 15 November) -- Managed Cardspace cards integrated with SAML/WS-Federation. Mike J. summarized this to "InfoCard auth to Federation"
    • Mike Beach gave an overview of the scenario for those not already familiar with it.
  • Scenario #2: Cardspace for authentication for SSO/federation, with special authentication context (summarized to: InfoCard auth carrying auth context)
    • Mike Beach gave another review and concluded that this was basically about leveraging Authentication Context across protocols.
    • Paul Madsen asked if scenario #2 is just a refinement of scenario #1.
    • AGREED: you would not have scenario #2 without scenario #1 so it is inclusive but you might have scenario #1 without scenario #2 therefore we will track them as distinct.

In the course of review a new scenario was offered up for consideration:

  • Concor Cahill suggested a new scenario that might leverage an identity selector to solve the IdP Discovery Problem where the Identity Selector could speak SAML ECP Profile (Enhanced Client/Proxy)
    • Paul Trevithic mentioned that this is what Higgin Project is trying to build SAML support for and there is a follow-up meeting Dec 17 in New York City to discuss this in more detail. Paul T. expressed this as an invitation to participate for anyone interested in a technical conversation about how to do this.
    • Paul M. pointed out that this simply looks like the Cardspace flows using the SAML protocols
    • Conor pointed out that there is another motivation for this scenario that brings new functionality to the SSO process, namely what SAML ECP support would provide to the Identity Selector that it does not already have is the capabilities associated with SAML Authentication Context.
    • Mike J. captured this new scenario as "IdP Selection, Auth Attributes but not list of claims".
      • Mike J. also pointed out that InfoCard does convey claims.
  • Scenario #3: Identity selector with ID-WSF Interaction Service.
    • Paul M. and Conor provided an overview using the following illustration... if I go to Amazon and they need my address they will ask my Contact Book Service and if I haven't given a pre-authorization to my Contact Book Service to give that information to Amazon.com it uses my Interaction Service to get permission from me at that moment based on the preferences I have set with my Interaction Service (e.g. IM or SMS).
    • This enables permission to be granted outside the flow of attributes, when the user doesn't initiate the flow
  • Scenario #4: Identity selectors integrated with SAML by means of the latter's Enhanced Client or Proxy profile.
    • This was already discussed during the explanation of Scenarios #1 and #2.
  • Scenario #5: SAML integrated into Higgins by means of SAML's attribute query profile
  • Scenario #6: WS-Trust integrated into ID-WSF token issuer/exchanger service.
  • Scenario #7: SAML authentication context as a univeral holder of Level of Assurance context information.
  • Scenario #8: Delegation... how does an identily selector support delegation of rights to other principals
  • Scenario #9: Metatdata optimization to better integrate Identity selectors wiht Shibboleth. This is related to Ping's "dynamic metatdata" activitiy spinning up in SSTC.

What Scenarios Are Missing?

Mike J. wanted to open the floor to consider new scenarios we might want to demonstrate at the RSA Conference that we have not yet identified in our use case analysis.

  • Scenario 10: Using selector to solve the IdP discovery problem using WS-Trust (same as Scenario #4 but using WS-Trust vs. SAML ECP)
  • Boeing made a clear point that supporting multiple protocols is more expensive on the consumer/deployer of these technologies and we really should be thinking about minimizing duplication of protocol wherever possible.
  • Mike Jones brought up Scenario 11: Chaining WS-Federation and SAML federations.
    • This seems to boil down to the "smart IdP" scenario discussed in the past where the IdP can talk more than one protocol to enable the federation chaining.
  • Paul M. brought up Scenario 12: Identity Selectors facilitating the flow of SAML 2 tokens
    • Mike J. pointed out this was an opportunity to coordinate with OSIS because the OSIS interoperability demo was going to explore this scenario.

Selecting the Scenarios for the RSA Conference

Next Mike J. moved the conversation from collecting potential scenarios to deciding on what we will collectively commit to demonstrating at the RSA Security Conference in April, 2008. Mike was working at the whiteboard with colored markets to depict what scenarios were "in" vs. "out". Below is the list of the scenarios that were chosen with some discussion of how to demonstrate interoperability and who is committed to participate in each scenario.

AGREED -- Scenario 1: InfoCard Auth to Federation -- is "in" the demo.

  • Who is going to participate with a SAML 2 implementation?
    • Sun Microsystems agreed to participate in this scenario
    • It was noted that most companies with SAML 2 implementations were either not represented or needed more time to discuss this internally before making a firm commitment.
    • ACTION: Brett will mine the list of Liberty Interoperable(tm) SAML 2 products for contacts to recruit into the demonstration.
    • In addition to that source folks through out some names like Shibboleth, openSAML, and PingID as likely candidates to participate.
  • Who is going to participate with a WS-Federation implementation?
    • Microsoft agreed to participate in this scenario
    • ACTION: Mike Jones to mine the list of WS-Federation implementations he mentioned for more candidates to participate in this scenario.
    • In addition to that some folks suggested PingID or IBM might want to participate.
  • Fugen Solutions agreed to participate in this scenario but it wasn't clear to the scribe if they were bringing a WS-Federation or SAML implementation (or both).
    • ACTION: Brett to get closure from Lena just what FuGen Solutions will be bringing to the Scenario 1 demonstration.
  • What will be involved in this Scenario 1 demonstration?
    • AGREED: We want to demonstrate that some protocols do some things and other protocols do other things. This is an opportunity to demonstrate various protocol capabilities and there is no need to avoid such comparisons in the demonstration. We should be showing both commonality and showcasing each protocol's unique capabilities.
    • AGREED: There is no protocol profiling required to facilitate Scenario 1.
    • ACTION: What is needed is the scenario definition for Scenario 1 followed by implementation effort by the various participants (to configure and enable their "smart end-points").

AGREED -- Scenario 2: InfoCard auth carrying auth context -- is "in" the demo

  • Who will participate in this Scenario?
    • FuGen Solutions will participate in this demonstration.
    • It was pointed out that this scenario, and the subsequent "levels of assurance" profiling work, applies to both SAML 2 and WS-Federation protocols.
      • Mike J. mentioned this may require WS-SecurityPolicy profiling to fully implement.
      • ACTION: Paul. M. will profile both WS-SecurityPolicy and SAML AuthnContext to convey the four levels of assurance that this scenario will require. Brett agreed to work with Paul to help faciliate that effort as it relates to the Liberty Identity Assurance Framework effort that Brett is working on.
      • The request for, and the comparison operator features will require WS-SecurityPolicy profiling but otherwise the SAML AuthContext could be entirely handled in the SAML token itself.
      • ACTION: Mike J. will talk with Don Schmidt and company about what they have already done with SecurityPolicy to enable this kind of profiling.

AGREED -- Scenario 11: Chaining between SAML 2 protocol and WS-Fed federations -- is "in" the demo

A high-level summary of this scenario is that the SAML IdP will need to act as a bridge for their SAML RP's so they can receive assertions from WS-Fed IdP's and vice versa. The participants should be able to carry common tokens.

Who is will participate in this demonstration?

  • Sun Microsystems
  • Microsoft
  • Oracle

Who are other key candidates?

  • Mike Beach mentioned that this is a use case that TSCP is dealing with today. Brett mentioned that he has just started to work with TSCP in the Liberty Identity Assurance Expert Group.
  • ACTION: Brett to recruit TSCP participants to be involved in the scripting of the detailed interoperability plan for demonstrating Scenario 11.
  • PingID was named as another likely participant.

Wrap-up discussion & Next Steps for the RSA conference demo

  • Scenario 10 is missing from the RSA demonstration but Boeing would like to see this developed further and demonstrated at some point.
  • Britta pointed out that the RSA demonstration is only the next demonstration opportunity but not the only one in 2008. She is already in the planning discussions with Burton Group about a Concordia demonstration at the Catalyst Conference.
  • AGREED: Scenario #10 should be a high priority use case for the next Concordia demonstration, perhaps at Burton's Catalyst Conference.
  • Scenario 13: "People Service/InfoCard integration" of adding a managed card claim for someone's Discover Service ERP is of great interest to some folks in the room and could be another high priority use case at the next demonstration.
    • AGREED: Someone should have an open space session this week to work on Scenario 13 further.

= Scenario Teams and Owners for the RSA Demonstration

AGREED: We need individual owners to lead the teams. AGREED: We can consolidate Scenario #1 and Scenario #2 into one team since they are so closely related. AGREED: Team 1 will own Scenarios 1 & 2 and members of Team 1 are:

  • Mike Beach
  • Mike Jones
  • Paul Madsen will be on the scenario design team but not be providing an implementation.
  • Lena Kannappan
    • ACTION: Paul will lead the scripting of Scenario 2.
  • All participants will need to support/display the authentication context.

AGREED: Team 2 will own Scenario 11. Members will be:

  • Upilli S.
  • Mike Jones
    • ACTION: Mike J. to recruit PingID members to participate on Team 2.

AGREED: When these teams hold calls it should be put up on the wiki.

Reminder that April 7, 9-12:30pm is the Interop Session at the RSA conference.

ACTION: Britta to take ownership of submitting a proposal for the next interop at Catalyst. Deadline is likely January unless Gerry G. gives us an extension.

  • TEAM ONE LEAD IS: Paul M.
  • TEAM TWO LEAD IS: Upilli S.

AGREED: We about a roadmap? Because some things are not being addressed.

AGREED: As long as the script achieves the use-cases it can go beyond so the point was made ID-WSF is not being demonstrated but someone could do that if they want to.

NEXT CALL: December 13 at 9am-11am PST and every 2nd Thursday of the month ongoing. The following call would be Jan 10th at 9-11am PST.

ACTION: Mike & Paul & Upilli will run a session on the Interop Scenarios at IIW this week.

Conclusions and next steps

[Details to be supplied shortly]

Retrieved from "http://projectconcordia.org/index.php/Meeting_Minutes_from_3_December_2007_Workshop"