Concordia telecon 13 Dec 2007

From Project Concordia

Attendance

Charles Andres, Abhilasha Bhargav-Spantzel, Mike Beach, Gerry Beuchelt, Conor Cahill, Scott Cantor, Peter Davis, Britta Glade, Jeff Hodges, Mike Jones, Lena Kannappan, Paul Madsen, Eve Maler, Shivaram Mysore, Charles Knause, Uppili Srinivasan, Roger Sullivan, Eric Tiffany, Collin Wallis

Infocard + Federation scenarios (1 and 2)

Paul Madsen has been keeping notes on these two related scenarios at the RSA IOP Scenarios page. A decision needs to be made as to how we will represent the authentication context; he has proposed URIs on that page, such as this:

concordia:rsainterop:sdac:personal

(Where SDAC stands for "specifics, derived assurance, or characteristics" in order to be inclusive of both detailed context data around authentication and identification, and rolled-up levels or other descriptors of assurance.)

The Identity Assurance Expert Group community in Liberty has heard of Concordia's interop-demo plans and a number of people expressed an interest in our showing interop of LOA. But this implies more consistent assurance policies across protocols and that the agent in the middle has to be able to map between authentication mechanisms. How does CardSpace do these mappings? They are baked in. Mike noted that CardSpace and other identity selectors are doing nothing explicit to carry authentication context to a relying party; it's all just claims. The authentication method used in cards is to authenticate to the IdP. If RPs want to know anything about auth method used, identity providers need to craft a SAML token with the appropriate info in it. CardSpace's equivalent of the SAML authn request limits what we can do here.

New Zealand noted this is of interest to them from an implementation perspective. With a managed card, you have more freedom to define attributes—this is done with SAML already today, but hidden from the implementation. There's an opportunity to uplevel this and translate it to make the request from CardSpace. This possibility was discussed at IIW, but the question now arose of whether this is displayed by the selector — and whatever the answer, is this good or bad? It would good for the demo!

Ultimately, this would be up to the IdP (in a real world scenario). The request for a security token from the RP is coming from an STS speaking metadata exchange which has a security policy statement, but the policy language is extensible and general. Could add a vocabulary asking for attributes and security policy — the IdP would produce a token containing the relevant attribute info for this.

Where are the constraints between the moving pieces? Or for the interop, do we narrowly define this? Are we looking at scenarios for an existing SAML infrastructure and trying to define something that works with existing capabilities as much as possible? How would the scenario work if there were multiple authentication mechanisms? Ultimately, we would like to achieve the original Boeing case study presented. We realize not all of this is possible today, but it's good in the interop to show pieces headed along this path.

Do we want to communicate specifics of (e.g.) two-factor authn, or a level-3 NIST assurance level? We are going to assume that the IdP presents/represents the information that they used to achieve the authentication. Let's distinguish between "raw" info and "cooked" levels of assurance (Paul's "derived" info in SDAC). Earlier we decided that we didn’t want to do this mapping — we should follow what others do who are experts— but people in places like Liberty’s Identity Assurance EG are interested in knowing this mapping would be possible and interoperable — providing the underpinnings for this later. We as technologists should demonstrate that we've heard this concern, but we'll have to build mapping work that's done later into the future work beyond our RSA roadmap.

So now we understand the different ways of conveying authn context info back to the RP. The leg of how the RP can do messaging to influence behavior is harder for protocol mapping. Scott thought that this is only needed by a minority of RPs since often the settings are simply static and not everyone needs the ability to dynamically request particular authn methods/levels of assurance, but if there's interest we could see the request side as a separate scenario to consider. Boeing did indicate that it has some use cases that support the need for this.

Let's call this Scenario 13 [would "CardSpace-authn'd SSO adhering to requested authn context" be a good name? -elm]. It needs the ability to not just move from SAML to SAML (which already has a way of doing this), but move through WS-* or any of the other moving pieces. IIf we were to try to extend/get around CardSpace’s assumption of how info is passed, this is a lot of work. If we leverage the functionality CS gives, mapping these levels into the middle IdP, this is where the burden lies, so it's not necessarily so tough. Abstract assurance URIs can just push all of this back (use unmodified passed tokens), so no mapping would be necessary. Unless the IdP is dynamically issuing new cards to people, you can’t do this dynamically. It's a matter of a user's card choice. Did the user use a card that satisfied the authentication request, or not? Let's not prioritize this scenario highly at this point.

GSA is apparently currently using SAML attribute statements to pass LOA information. Instead of working directly with the SAML authn context data structure in making a bridge to CardSpace (for the entire scope of SDAC), perhaps we can define an attribute profile, effectively turning this into a proposition of standardizing some "SDAC claims" that could be used in pure SAML, SAML+CardSpace, or whatever. Today, people use SAML for SSO in a way that doesn't involve the requesting of specific attributes. In CardSpace, it's sort of combined in (the request for claims amounts to a request for what, in SAML, would be specific attribute statements). Some have wanted to be able to use SAML more smoothly for this scenario, so perhaps the two technologies are not as far apart as originally perceived.

It would perhaps be useful work for the SSTC to define a managed card structure that allows you to do many of the things in an authn request. What are the implications for metadata profiling/mapping/translation? How to get the right security data through?

Paul has questions around WS-Fed's handling of authn context-like capabilities, and he's looking for information on this in order to complete his homework on the Scenarios 1/2 design team.

WS-Fed + SAML scenario (11)

Regarding Scenario 11, we don't seem to have a design team yet; Brett has an action to find volunteers for such a team.

Scott notes that there was a Catalyst multi-protocol demo done years ago on this scenario; unless we get more specific about real-world gotchas we're solving, "gateway" interop demos aren't very interesting. We want to be able to show value-add against this.

Going by the interest expressed on the call, most of the energy right now is with scenarios 1 and 2.