Shibboleth Developers

["Scott Cantor" <>]

> The basic idea is to have a set of profiles for "X.509 Subjects", that
> is, SAML assertions and profiles built around the X509SubjectName
> identifier.

Yeah, I'm just not convinced of the need for some of your constraints on the
relationship between SAML and certificates. Maybe for some deployments, but
that's a policy not a profile.

> I think I know what you're going to say :-)  "You have to invent a
> whole set of new profiles just for X509SubjectName!"

If by that you mean I'm going to say I think X.509 subject naming is
orthogonal to all of these profiles, then you're right. I see no reason why
it's relevant to anything. Names are just names, and attaching meaning to
names inside of deployments is not a SAML thing, it's a deployment thing.
That's why I think all the old formats are useless and interchangeable.

> I hadn't considered an entirely new element on the IdP side (we
> already have one on the SP side).  That's an alternative to an
> extension attribute, I guess.  I'll have to think about that.

These were the two principal design options:

<Service Profile="URI" Location="URI" Binding="URI">

<FooService Location="URI" Binding="URI">

They chose the latter. It's simpler to search with XPath, it's how Liberty
metadata looked, and we're not reinventing WSDL.

> Well, but there is no SAML 1.x attribute exchange profile.

To the extent that there's a SAML 2.0 profile, yeah, there is, it's just not
explicit in the old specs. The only reason it's explicit now is for
conformance reasons. The 2.0 profile constrains virtually nothing, it just
says "hey, moron, you can send queries with SOAP". The implicit 1.x profile
is effectively the same.

Shibboleth required an explicit query profile mainly because I lost the
argument to include Issuer in SAML 1.x protocol messages.

> Does an extension profile qualify?  (Not sure when a profile warrants
> to be called an "extension")

The issue is compatibility. When you can send messages of both a basic
nature and an extended nature to a single endpoint and it's possible for the
receiver to process both and unambiguously, there's no need for a different
element because all you're doing is adding to what's already indicated. You
can add optional attributes to signal support for things without affecting
existing client code.

In this case, it's just a matter of whether you expect a single endpoint to
respond to both 2.0 queries and whatever you think this other thing is. It's
not clear to me yet why this other thing is even needed if it is within the
bounds of a deployment of 2.0 query behavior.

Making certain security features required is a deployment choice, not
necessarily a profile. When BAH originally proposed it, I said "why do we
need a profile if the conformance spec already makes all those knobs MTI?"

-- Scott