Concordia telecon 15 Nov 2007
From Project Concordia
Attendance
Charles Andres Mike Beach Jeff Bohren Jeff Broberg Scott Cantor Martin Euchner Sergio Fiszman Britta Glade Adrian Gropper Patrick Harding Ashish Jain Mike Jones Hubert Le Van Gong Paul Madsen Eve Maler Brett McDowell Shivaram Mysore Dale Olds Roger Sullivan Eric Tiffany Bill Washburn
Summary of AIs
New:
- Britta: Look into dial-in line for Concordia workshop at IIW 2007b
- Britta/Charles: Coordinate any joint OSIS/Concordia interop activities for RSA
Still open:
- 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
- Eve: Create a wiki page to hold our IdP discovery education material
- Eve: Consolidate use case/scenario material on wiki and make it easier to find
- Brett: Review wiki and suggest how to highlight eventual Concordia-inspired technical work
- Mike J.: Send out a message asking for technology provider interest after Eve's notes go out
Review goal of telecon
Proposal: Tee up substance of concrete use cases (we decided to call them "(interop) scenarios" later in the call and I've used that throughout). Agreed. Eve asks for people to utilize the community@projectconcordia.org mailing list for discussion in between telecons, workshops, and interops!
Logistics of next F2F workshop at IIW
We are planning to hold a workshop on Monday morning, December 3, at the Computer History Museum prior to the official start of IIW 2007b. We anticipate that wifi access will be available. Britta is following up on A/V needs. Scott requests a dial-in line, and Britta will look into doing that as well, though it can't be guaranteed.
Logistics of RSA interop setup
Britta has been coordinating an anticipated Concordia F2 event/presence at the RSA conference 9am-12:30pm on April 7, with setup access (and usage for any purpose) all day on April 6. The conference organizers have asked us to provide an abstract for the event, which we're about to submit. For the workshop/interop, the organizers have asked for relevant logos for the print brochures -- and this is due today! The web info is more updatable.
Mike Jones has offered up a Microsoft logo and we'd certainly like as many other logos as people are willing to offer, in addition to the Project Concordia one. Once Bill Washburn joined the call, we asked him if we could use the OpenID logo for the RSA conference materials and he agreed.
(Britta has heard interest from Gerry Gebel in Concordia submitting ideas for Burton Catalyst activities, starting in January, so we should think about that.)
Mike J. reported on an OSIS/Concordia coordination call held a week or so ago. Those of us who met agreed that while we'd stay in coordination, it seems that some use cases are outside an intersection of interests. A lot of people are involved in both, in any case, so we can easily keep tabs. OSIS has reserved its own room for interop activities at RSA for two days (we think it will be the Tue/Wed, i.e. not overlapping with the Conconrdia days, but it's not confirmed yet), and it also will be settling its interop scenarios by IIW 2007b. So time is of the essence.
Britta offered to be a point of contact for OSIS/Concordia logistics coordination with Charles Andres.
Deep dive on identity selector-related scenarios
We started documenting potential concrete scenarios, and we'll just number them consecutively throughout all future ones identified. Mike Beach of Boeing had sent Eve some thoughts on this, and these formed the first few we identified today.
Scenario 1: Managed CardSpace cards integrated with SAML/WS-Fed federation
Boeing has ~.5M employees, former employees, etc. to whom they provide various services through a Boeing portal. They use SAML and also some WS-Federation to interact with the service providers. They use username/password but aren't happy with it, nor with the interface it involves, particularly for retirees. He has been thinking about Boeing becoming a managed card issuer for improved security (certificate-based, two-factor).
A second phase could involve not having to provide a highly available portal, with users accepting the Boeing-managed cards. PII does have to be shared with the third parties. This scenario doesn't seem to need to convey authentication context information about info card use to RPs.
A team is currently actively struggling with what can be done that's cost-effective and usable to improve security for this use case.
Scenario 2: CardSpace for authentication to SSO/federation, with special authentication context
Boeing's trans-global secure collaboration project has a strong interest in conveying information card-related authentication contexts to partners. This case seems to be able to entirely separate the authentication process from the federation/SSO process (essentially, it is CardSpace used for authentication). This is distinguished from scenario 1 in that the CardSpace involvement in authentication would want to be shared with RPs (in a SAML authentication context?).
Discussion of both scenario 1 and scenario 2
Scott asks about the issue of starting both of these processes with an initial authentication that is still likely to be password-based. Boeing is struggling with this too, and is also considering something like a mailed-out PIN. Scott notes that the SSH model (starting with a private key associated with an account) seems to be common here -- and Shivaram notes that self-signed keys are common too, but this is impractical for .5M people.
Ashish asks why a managed card is necessary. Mike B. acknowledges that it need not be -- but they just want stronger authentication than username/password alone (e.g., two-factor would help -- maybe a card that supplements username/password?). This could have impact on what we choose to interop-test, but we realize we could easily get into the weeds of design here! Boeing hasn't spent any design energy on this because CardSpace has no penetration in real-world deployment.
Scenario 3: Identity selectors with ID-WSF Interaction Service
Hubert shared recent discussions in Liberty TEG about how identity selectors could work with ID-WSF user interaction models. ID-WSF would be doing the web services transactions and, as required, invoke an identity selector whenever it needs to get more user information or consent. With real-world ID-WSF deployments available now, this becomes more interesting.
Scenario 4: Identity selectors integrated with SAML by means of the latter's Enhanced Client or Proxy profile
Scott comments that it's a potentially rational approach to integrate SAML and identity selectors in Higgins by using SAML's Enhanced Client or Proxy profile. There's a gap between rich identity-selector functionality and the lightweight functionality of ECP. ECP is a "somewhat smart", "somewhat active" client that uses HTTP in a clever fashion to interact with web services, and also can be pre-provisioned with IdP endpoints.
Any work we do to define this scenario further could feed not only into Higgins plans but possibly also OSIS testing if they're picking up on Higgins work here.
Scenario 5: SAML integrated into Higgins by means of SAML's assertion query profile
Dale comments that in the in-depth Higgins design discussions, it's early days for SAML. But the general idea is that there would be a context provider (a plug-in into the JNDI-like Identity Attribute Service, or IDAS) that could use SAML to retrieve attributes underneath an STS. Others on the call thought that this might, then, use the generic SAML assertion query protocol profile.
Scenario 6: WS-Trust integrated into ID-WSF token issuer/exchanger services
Eve mentions the complementary notion of putting an STS underneath, or using it alongside, some of the identity services defined by ID-WSF. These likely include the Discovery Service, the Authentication Service, the SSO Service, and the Identity Mapping Service.
Scenario 7: SAML authentication context as a universal holder of Level of Assurance context
Eric comments that the E-Authentication group, as well as other global agencies that model themselves after it, is doing a lot of work around levels of assurance, and wonders how the SAML authentication context data structure can be leveraged for consistent LOA representation in an identity selector environment. Although discussion is ongoing in other forums, we can collect and comment on the state of the art.
Scenario 8: Identity selectors integrated with access delegation
Eric notes that the Liberty E-Government SIG call yesterday touched on the issue of delegation in an identity selector environment. You'd like to be able to delegate your activities online to another person, or to a group. Eve comments that current approaches range all the way from brute-force impersonation by sharing passwords to sophisticated access control (of the ID-WSF sort, e.g. involving the People Service) to functions normally considered to be in the province of the main principal. But delegation per se is often not done in fine-grained fashion.
Scenario 9: Identity selectors integrated with Shibboleth
Scott comments that Shibboleth is at the early stages of use case development, and today what is supported is the most trivial usage of CardSpace for authentication. Some work is likely to be needed to do metadata profiles for CardSpace interaction alongside SAML (much like they've done with WS-Federation already).
Deep dive on dynamic web SSO scenarios
Patrick Harding presented on this topic; see the slides sent to the list. Ping Identity has been working on this and talking to various people about it for some time now. The focus is on B2B federation leveraging the SAML protocol, which they're seeing a lot of. For example, the IdP-initiated form POST pattern is common. But the federation connections sometimes take months to set up. The hope is to break through point-to-point costs to get to dynamic setup.
He notes that 401K and healthcare use cases are actually an exception to the rule of RPs being happy to outsource authentication, despite their being used as canonical SSO use cases.
The proposal he's making includes replicating the success of email for dynamic connections. A requirement/constraint, though, is to work within SAML as standardized today, just adding conventions people can use. Slide 8 contains high-level notes on their concrete technical proposal.
It's desirable to develop conventions, as well, on the sorts of attribute schemas that the endpoints require support for and handle. He's a bit skeptical of efforts to merge together all the common schemas into one.
Ping is incorporating feedback through the end of the year.
(Where "Discovery Service" is mentioned on slide 8, he's referring to the general IdP discovery problem, sometimes known as WAYF or Where Are You From, rather than the ID-WSF Discovery Service.)
Some people have mentioned to him that XRDS is interesting as a metadata technology to employ in a dynamic web SSO solution. At the moment, today's pain points are around SAML metadata specifically and he's concentrating on that for now.
Scott comments that Shib's overriding interest is in getting products to interoperate. All the problems Patrick was talking about, Shib doesn't have! (Except for IdP discovery.) He'd like vendors to be implementing "usable SAML products". The most straightforward way of doing this is to separate the considerations of run-time trust operations and metadata exchange operations.
Shib is interested in creating a profile (likely in the SSTC) that deals with these considerations separately, constraining run-time behavior severely and makes metadata exchange a more open field for trust authority model experimentation. They want metadata to become self-describing and therefore implicitly trusted, which means getting rid of the PKI runtime (OCSP, revocation, CA, etc.).
Shib believes that everyone's trust model approaches need to be accommodated, and can be if metadata is self-describing. Patrick agrees. Handling metadata out of band, manually, is a killer.
Eve asks if the intent for IdP (and metadata) discovery is for a user to walk up to a new SP, plug in their personal email address, and have the SP contact an IdP they've never talked to before in order to get metadata to allow them to set up a new relationship. Patrick says that in a B2B context, typically there has indeed been a business relationship already set up, and all that remains is to get the technical relationship set up. SPs already often see email addresses in the clear -- but Eve notes real-life B2B use cases where the user's identity must not be revealed. Is having a user simply provide a raw domain name feasible? Patrick observes that using information cards can also take care of discovery.
Scott comments that WAYF services don't tend to scale across use cases where an SP interacts with a large number of communities. Unless we reinvent DNS, solutions tend to fall apart pretty quickly.
Eve puts in a plea for individual pieces of the problem to be solved individually (fine-grained) and then perhaps aggregated into larger chunks (best practices, conventions, profiles, deployment profiles, whatever) to solve particular interop problems. And we should look at doing some interop testing of some of these solutions at RSA, if we can. That will mean identifying one or more clearly distinguished scenarios, and possibly feeding them into any profiling efforts at the SSTC or elsewhere.
Mike B. comments that Boeing has solved the IdP discovery challenge through their own proprietary approach. They would like to see a standard way to do this, no matter whether they're using WS-Fed, SAML, ID-FF, or even OpenID eventually.
Summarize highest-interest scenarios identified today for April
Everyone wanted to ponder what we've discussed -- but we need to nail the choices down by IIW 2007b and hit some tough deadlines for writing them up in a way technology providers can use for RSA.
Scott reminds us that we have an action item to collect IdP discovery methods, pros, and cons, and we should get to it.
Do a bit of IIW workshop agenda/deliverable planning
Mike J. has graciously agreed to facilitate this workshop.
Brett suggests that we begin collecting interested parties who potentially want to take part in the RSA interop and use this input, as well as the continuing input of deployers, in choosing scenarios to sharpen up for interop activities. Mike agreed to send out a message asking for technology provider interest after Eve's notes go out.
Brett suggests that a reasonable outcome of the IIW workshop would be to refine our A-priority use cases (now that we have the potential scenarios identified above), and then get vendors to weigh in on which of them they're willing to demonstrate interop on by April.
Eve adds that we should try to get to the same point on dynamic web SSO scenario prioritization by IIW as we are on the identity selector scenarios, so that these can be considered for the RSA timeframe as well.
