We’ve been discussing the problem of “dynamic web single sign-on” in the Project Concordia workshops and calls, knowing that the Ping Identity folks were planning to come forward with a proposal and anticipating that others would have feedback and possibly counter-proposals to offer.
Patrick Harding has posted some details of the Ping proposal just today. We’re hoping to refine some “dynamic”-related interop scenarios in the upcoming Concordia workshop on December 3 before IIW 2007b begins (if you’re attending the workshop, please add your name to the new participants list!). The timing is good to have some technical proposals to chew on.
For context, here’s some of the discussion we had on our recent telecon about this proposition:
Scott [Cantor] 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.
Here are some questions off the top of my head.
- It looks like Patrick’s mention of an “optional” email-address-based mechanism for deriving the metadata location is a nod to my plea for separating the pieces of functionality — I was particularly worried about depending on the sharing of PII like an email address to make this work (e.g., Sun’s most famous enterprise-outsourcing federation is with BIPAC, and there we keep the individual identities of Sun employees shielded from the service provider). Others have discussed just having a user provide the domain name of the IdP (sort of like in OpenID directed identity) rather than their personal email address. What’s most practical here?
- Scott has an interest in preserving the ability to use many different trust models. Does Patrick’s proposal achieve this? If not, how should it be changed?
- Is the scenario set/problem space correct? I don’t think it’s practical to dramatically extend it, but my BIPAC example above is straight down the line of the stated scenarios to be covered, except for the expectations of privacy.
- Something I’ve talked to Patrick and others about is how we can take the opportunity to ease negotiation around required/handled attribute namespaces through metadata. What scenarios should be included to cover this, if any?
It’s killing me that I won’t be at the workshop (I’ll be on vacation next week), so I expect y’all to figure everything out by the time I get back. OK? OK.
