Shibboleth Developers

["Scott Cantor" <>]

> Has the community addressed the particular use case that an "InCommon-
> participating" university with a commercial (non-Shib-project) SAML2
> endpoint may seek to rely on assertions from a college operating only the
> traditional shib endpoints (particularly for the next year, or so)?

At the moment, InCommon does not support the use of SAML 2.0 at all. What do
you mean by "traditional" endpoints? SAML 1.1? The answer would be no,
InCommon does not run any gateways, and I doubt it will. I also don't think
it likely that any gateways will be registered somehow as InCommon members,
at least not without a change to the policies.

> Do the rules for InCommon allow for a participant to offer SAML2 endpoints
> that (a) are provided for by a SAML2 implementation other than that from
the
> Shib development team, and (b) may put user in the position of being
unable
> to interwork with other InCommon participants still using the Shib-profile
> of SAML1.1?

InCommon does not yet address the use of any SAML2 endpoints at the present
time. When it starts supporting this, there is no plan to provide a gateway
or guarantee connectivity between incompatible protocols. Any two sites that
wish to can agree to use any protocol(s) and options they share.

It may eventually happen that InCommon attempts to define a subset of SAML
2.0 that sites MUST deploy to improve interop. There are no specific plans
for that, but it could happen.

As far as software, that's orthogonal. InCommon's position is to support the
use of the Shibboleth System, and allow members to use any complaint
software as long as they're willing to support themselves. InCommon won't
accommodate non-standard metadata, for example.
 
> Does this use case call out for bridging gateways - between SAML1.1 (shib
> profile) endpoints and SAML2 endpoints?

I don't generally like gateways, and I think they usually violate privacy in
this context. Others disagree. I think the biggest tactical risk is that it
would basically ensure that most people never upgrade, at which point they
end up running unsupported software altogether. I'd rather build smart
endpoints that help manage the transition, and so I have. I think there's
room for both approaches, and people can choose.

> Then, we will try remove the bias, which is based on a general thesis
> that has yet to be well tested: use one set of trust channels (those
assured
> by public CAs) to bootstrap peer-to-peer trust in the self-signed entity
> metadata.

I realize I'm jumping ahead, I'm just saying that I don't believe that
thesis holds. It will certainly hold when the participants just don't care
enough about the security of the application to worry about it, but I think
a good model needs to address a wider range of needs.
 
> However, having now built the concept, there certainly are
> valid counter arguments, I've found. There are various topics worthy of
> formal research concerning OpenID interaction with SAML's model, above and
> beyond implementing bits of software.

I'm not saying otherwise. I just think those pieces are orthogonal to
whether or not somebody likes XML or not. There's important stuff in there,
I just wish it had been raised differently.

-- Scott