Concordia telecon 15 Aug 2007
From Project Concordia
letoelor
Contents |
Agenda
- Discuss how to make good use of the DIDW workshop slot
- Select 2-3 "June use cases" that we'd like to define/promote further, taking into account OSIS needs
- Drill down more on defining at least one June use case
- Wiki organization
Action items
- Bill Washburn to approach Johannes to present use cases
- Gerry, Ashish, David, and Eric to propose, at Monday's OSIS call, that the October interop focus on the "mashup" aspect and that the April interop focus on protocol-level interop
- Eve to fix wiki page for these notes to say 15 Aug instead of 17 Aug! - done
- Mark to send out info on the Identity Schemas mapping work/progress - done
- George to share ideas on scalable federation use cases
- Britta to ask the list to opt in to the publicity planning around the DIDW workshop - done
- Eve to follow up on the idea of holding another telecon prior to DIDW
- Eric to do some major surgery on the wiki's main page
- All to blog about the upcoming workshop!
Attending
Eve Maler, Roger Sullivan, Jim Heaton, Gerry Beuchelt, George Fletcher, Mark Wahl, Bill Washburn, Hubert Le Van Gong, Eric Norman, Brett McDowell, Britta Glade, Abbie Barbir, Ashish Jain, Drummond Reed, Jeff Bohren, David Recordon, Sergio Fiszman from Nortel, Peter Bachman
DIDW workshop planning
Brett has recruited additional people to share more use cases, e.g. from the healthcare, energy, and higher-ed sectors. He's gotten tentative commitments from the last two.
Eve is suggesting that we spend some time formally defining one or more use cases (inputs, outputs, assumptions, etc.).
Roger pointed to a previous suggestion by David to bring in OpenID deployers to collect more use cases from them. Roger would like to see both pushing forward with selected use cases and continuing to gather more. Eve suggests therefore using the first part of the workshop to work on pre-selected use cases, and the latter part on gathering more data so that we don't get into analysis paralysis.
Eric suggests adding a matrix to the wiki to catalog identity systems software users. The four major players are OpenID, CardSpace, Liberty, and Shibboleth, in that you have to "install their software on your equipment". The rows could be the capabilities available to the user, and the columns could be the capabilities available to the relying parties.
Sergio wants to organize systems based on what they are "centric on". E.g., user-centric (OpenID), application- and web-centric (many commercial systems), and network-centric. There is not today a seamless integration between these. Integration of attributes is needed.
Eve suggests working on use-case writing from noon to 2:30, break from 2:30 to 3, hearing from a couple of identity technology users who have new use cases to present from 3 to 4:30, and determine next steps from 4:30 to 5.
We discussed further who we should try to hear from further. Healthcare is of particular interest because it has strong privacy, security, and risk issues. Johannes Ernst could be good for healthcare+OpenID use cases. "Higher ed" generally translates to Shibboleth, though we anticipate that a presenter might give us input specifically on Shib+ADFS interop issues. Dave points out that we want to find out how deployers want to solve problems, not just what they're doing. Eric describes people in higher ed alighting on OpenID as a technology of interest, but discovering that the campus as a whole only cares about Shibboleth. Higher ed has very decentralized decision-making.
Select use cases and consider OSIS needs
Eve has made an attempt to put together "general use case categories" on the wiki's main page, feeding in the input from the use-case presenters and various email threads. Are the categories valid and useful? It seems so. Jim Heaton (of GM) feels that multi-protocol SSO/SLO is at the top of the list. George Fletcher (of AOL) notes that before you get to exchanging data and invoking identity services, you have to solve the SSO/SLO process first.
Eric says the first problem is "sign-on", not "single sign-on"! Another way of saying this is that the authentication issue is primary. If a site doesn't support CardSpace and it's your only choice, you have a problem. Jim agrees.
George notes that there are two places to solve such a problem and take the burden off the user. One is to get clients to pick up the slack, and the other is to get RPs to pick up the slack.
The "Protocol brokering for device-to-web SSO" general use case should be merged with the "Multi-protocol SSO and SLO" general use case, with two specific use cases that make different assumptions: a smart client doing protocol brokering vs. a relying party doing protocol brokering. Eve broaches the idea of a "cascade" through these options, with the client solution preferred -- but Eric pushes back, saying you have to do risk assessment first. And George says the user might want to set preferences or let the two sources of brokering battle it out. So let's keep them decoupled.
David notes that the OpenID community is struggling with, at the client, how you can discover what protocols the RP supports. Concordia could maybe publish UI best practices.
Sergio comments that, in discussing SSO, you might be "roaming" across different networks. The conditions that must be taken into consideration need to be documented. An employee in an enterprise could be logged in using a portable device, and might continue from a private network to a public network. The security context might need to be preserved across this gap. Eve notes that some of this info is captured in a data structure for the security context, and other parts of it may be implicit.
Eve asks if the OSIS interop plans center on the multi-protocol SSO issue, as she suspects. Eric says OSIS doesn't want to get into interoperability testing of mixed protocols for the near future. Gerry disagrees a little; there's some interest to demonstrate authentication into an OpenID provider using InfoCards. If the Concordia community feels these sorts of cases are important, we can provide that as feedback. Ashish believes the OSIS community is more likely to target April than October for multi-protocol interop (Brett characterizes this as "Concordia interop"!).
Eve would like to see any "magic" invoked in API-based multi-protocol interop surfaced in the form of protocols or gateway standards or formal mappings. E.g., if tokens are being magically transformed from one form into another, documenting this for all to see and use is very valuable. To her mind, this is a key contribution that Concordia can foster.
Ashish asks: Is CardSpace authentication into OpenID "interop" or a "mashup"? Good distinction! David thinks that, regardless, there's value. If you have a way to characterize the act of authentication as having been based on CardSpace, that adds something new and it might be an OpenID extension. Gerry proposes a way forward on conveying preferences in the OSIS meeting.
Eric advises caution in encouraging mere "mashups"! This just requires people to deploy multiple systems.
Peter suggests capturing the total set of interactions of all the protocols in one simulation. This can help construct benchmarks to inform users of known issues. Maybe someone involved in this community could host it. Brett interprets this as a master gateway/translator, or maybe it could be a Flash demo. This could be the anti-version of George's nightmare-scenario login dialog!
What are specific use cases in the first general bucket that we might consider? Each of these makes a different assumption about which party is able to take up the slack.
- Smart RP: RP declares to the client which protocols it supports in case the client is able to make use of these as hints for simplifying the authentication/SSO interface
- Similar to content negotiation
- Example: VeriSign pops up browser window on seeing evidence that OpenID is supported
- George has published an idea of how to solve this with microformats
- The Web SSO Metadata Exchange spec from Sun and Microsoft also had a solution for this
- Issues: What assumptions are we making about the "smarts" of the client? Are these each their own use case? George advocated earlier that this should be decoupled from the smart-client question
- Smart IdP: Gateway IdP serving as a proxy to an IdP that speaks protocol B accepts authentication requests from RP1 in protocol A, converts into protocol B, and converts response from B to A for RP1's consumption
- See Peter Williams/Pat Patterson thread about OpenID-into-SAML
- Do we assume that RP2, regardless of the protocol it speaks, will be able to make use of the same active login session? If they're dealing with "the same IdP" as far as they're concerned, then always yes
- Many complications here, which get into the impedance mismatches between technologies; e.g., OpenID and SAML's Web SSO have different rules for what an authn request contains (identifier or not), and CardSpace and SAML ECP assume all flow goes through client while others don't
- Smart client: Client device that can successfully make a match between whatever type of login an RP site can deal with and the available identifiers of the user's that the client is aware of
- Is likely to take advantage of the of a smart RP's declaration
- Browser plug-ins could count here, including password managers, as long as they have a way of interacting with the RP site
In the "scalable federation" general use case bucket, here are some potential specific use cases (very random ideas):
- A new "introduction protocol" that would allow a user to introduce the IdPs of two arbitrary identities that they hold
- Eve mentioned this idea briefly here
- George idea for the ability to figure out, for the user, who their IdP is, and then invoke the IdP with their native authentication protocol, then verify their ISP with a back-channel query, then treat this as a new provider in your circle of trust
- He'll think more and share details as he's able
- Brett note about Liberty's new Identity Assurance group, which is cross-protocol in that it's not protocol-related! -- involves policy around trusted authorities
In the "attribute exchange" general use case bucket, the Identity Schemas Working Group is already working on the specific use case of mapping between attribute representations. See http://idschemas.idcommons.net/moin.cgi/MetaData?
Final thoughts and next steps
Eve asks: How should we let people know about the upcoming DIDW workshop? The workshop done at Catalyst did have some formal publicity (a press release) done for it, which generated enthusiasm for the activity and the community. The room at DIDW will fit 60 people theater-style. We may also want to open a telecon line during the workshop. Britta will follow up. Everyone should also blog away on the subject.
