Concordia telecon 22 Apr 2008
From Project Concordia
Contents |
Attendance
Eve Maler, Dervla O'Reilly, Britta Glade, George Fletcher, Mike Beach, Brett McDowell, Scott Cantor, Damien Carru, Ashish Jain, Ari Kermaier, Colin Wallis, Bill Young, Jeff Hodges, Vijay Simha, Mahalingam Mani (known as "Mani") from Avaya
Next meeting
We're going to switch our "standard hour" for telecons to 11am-noon Pacific on Tuesdays, and our next telecon will be 6 May 2008 at that hour. This will help a number of people attend on a more regular basis.
Concordia futures and relationship to OSIS / upcoming F2F opportunities
At the OSIS steering committee meeting, the topic of OSIS/Concordia similarities was discussed. Someone commented that if OSIS were to do a press release, it would look very similar to the Concordia press release. Confusion and fragmenting may result if we continue without tighter coordination. A distinction between them to date has been Concordia's involvement with deployers and their use cases, but there are still a lot of similarities. Some people thought we should somehow merge.
What would a merging look like? The OSIS steering committee wondered if OSIS should do workshops (interop workshops?) and Concordia should do deployer input (which Eve notes is often conducted at F2F workshops).
Mike Beach notes that Concordia's charter is friendlier to enterprise, with mention of WS-* and SAML and such, and OSIS is more about open source and consumer-related technologies. Might Boeing lose interest and go away if we were to merge? Brett notes that the media has paid attention to the Concordia "brand" because of the deployer role.
Britta mentions that Burton is interested in Concordia doing another workshop at Catalyst in June (based on Britta's outreach, mentioned back last December), and that Roger Sullivan has gathered deployer interest in offering use cases and feedback on the XACML/policy, which perhaps we could do at such a workshop. Ashish reports that OSIS folks haven't focused on Catalyst yet because of the European ID conference going on this week.
Eve proposes that we all, at the least, coordinate joint messaging for the Catalyst timeframe. Brett has a concrete proposal: As one way of connecting, Concordia can work with deployers to gather feedback on OSIS scenarios. Ashish comments that this could be useful because OSIS is set up more as a vehicle for technology providers. We can also get OSIS feedback in the process of prioritizing our next bunch of Concordia scenarios (see below).
AI: Brett agrees to cycle with Mike J. on further discussion and coordination, including the possibility of some sort of joint meeting at IIW in mid-May to continue the discussions.
(See Mike Jones's later followup email, in which he notes, "The main point about Concordia/OSIS coordination is that it doesn't make sense to ever give the appearance of there being "competing" interops again. No, they weren't competing really, but that wasn't at all obvious to outside observers. The appearance caused actual problems for at least one strong Liberty supporter, for instance. Roger and I don't think actual merging makes sense for a lot of reasons but having Concordia primarily collect and act upon use cases and OSIS primarily run interop events (some of which may be co-branded with Concordia and include Concordia use cases), and having both the appearance and actual tight coordination between the two efforts does. I'll be glad to talk about this on the next call.")
Further deliverables on Scenarios 1 and 2
There was consensus at RSA that formal profiling (a la work done at SSTC these days) and formal interop testing (a la work done at Liberty these days) would be useful.
Scott and Jeff indicate interest in helping out with formal profiles. We think these might include an InfoCard profile for SAML: e.g., authn context representations, requesting SSO assertions and responding with them, profiling bearer tokens, and dealing with the claim type vs. value limitation. One live-wire issue is whether we should follow the protocol or the implementations! The InfoCard protocol has support in it for things like transmitting policy, but the CardSpace implementation doesn't support this feature yet. Perhaps we should profile InfoCard itself for this purpose. (Mike B. brought up the immaturity of CardSpace at RSA.)
Eve notes that Boeing and NZ SSC both have representation on the SSTC. Bill thinks that an InfoCard profile of SAML could wait a while, until implementations in the market catch up, because deployments are realistically years away. Scott dissents, on the theory that implementations can be influenced and incentivized by a profiling effort. Mike B. agrees with Scott.
Eve observes that the earliest SAML1.1 interop at an RSA conference helped to inform the ongoing ID-FF, SAML2, and Shib work on SP-initiated SSO, a scenario that was demo'd at that interop (governed by an extensive scenario document) but was not part of standard SAML flows yet.
SSTC members on this call agree that we should be able to get a stable SSTC Committee Draft quickly -- Scott thinks by mid-summer! We could target winter 2008-2009 for formal interop testing.
Eve relays news from Pat Patterson, who's traveling today: He will publish a small extension to OpenSSO that reflects the sum total of code written for the RSA workshop interop event. This would be available to anyone to look at and use. Colin asked if this applies to SSOCircle -- yes, it does, if they choose to use/build on the extension.
The WS-Fed wauth parameter stuff might need a protocol translation profile; perhaps this should wait until WS-Fed itself is a final OASIS Standard.
There's room for a WS-Fed<->SAML (Scenario 2) mapping profile as well; Scott is willing to help anyone else who wants to write such a profile. Mike B. notes that the TCSP effort is still ongoing, so we might want to wait for their further input. No one else expressed urgent interest in working on such a profile right away.
Variants on Scenarios 1 and 2
Bill notes that the NZ SSC IVS scenario includes a user using a selector to get their IVS card, which would in turn want to use a managed card to authenticate the individual. This is what Eve had been calling "managed card proxying" at the RSA workshop when Danny presented. Scott thinks this may be allowable per the InfoCard protocol (which he believes allows full recursion), but isn't supported in the CardSpace implementation. Bill will check out that possibility.
Other scenarios to consider
NZ SSC also has an interest in InfoCard bootstrapping to ID-WSF. (This is in addition to earlier interest that had been expressed in OpenID bootstrapping to ID-WSF.) These form a natural bucket.
AI: Eve to reach out to Peter Williams to ask for use case input on OpenID + SAML.
Mike B., among others, indicated interest to Roger Sullivan on fine-grained authorization use cases (likely involving XACML).
Another that may (or may not) be a live wire: InfoCard+SAML Enhanced Client. A number of research papers have been appearing on this subject.
