Shibboleth Developers

["Scott Cantor" <>]

> The first one does that, yes, but what about the second
> (Conditions/@NotOnOrAfter)?  How can the assertion be "valid" if the
> NameID is invalid?

I really don't want to get into a debate about validity, because it's a
squishy concept. Read the X.509 specs for example. Technically, the validity
of a certificate says nothing about the "truth" of the data in it, it
dictates how long the CA is promising to maintain revocation data for it.

SAML is no more, and perhaps even less, clear on it. Shibboleth is just as
bad.

What does it mean for a NameID to be "valid"? Even less clear. It's not even
worth thinking about, to me. The bottom line is that you can stop looking
for this in SAML because there is no way to communicate it, whatever you
think it means. So you can put it anywhere, essentially, if you really need
it, but only your app will grok it, which might be fine.

> Yeah, this is off topic (I really should send this to saml-dev) but I
> think transient identifiers are woefully underspecified.
> The Shibboleth language was inherited by SAML 2.0, but I'm left with an
> empty feeling about them.  We've been trying hard to leverage
> transients in GridShib but it has been very, very difficult.  We can't
> make any assumptions about them, which renders them pretty useless for
> our purposes.

Your purposes. What about others? They work perfectly fine for
session-oriented exchanges and the point of them is to preclude people
storing them outside those sessions.

BTW, if you think the spec needs clarification, security-services-comments
is the place to send that, not saml-dev, but you should probably make
specific suggestions.

> I think profiles should have something to say about identifiers,
> especially transients, but none of the SAML2 profiles even mentions
> this.  I think that's a problem.

I don't, because the only profiles in SAML are either session-oriented (all
the SSO and related front-channel stuff) or completely independent of this
sort of issue (attribute queries, where the identifier is out of scope).
When you try and merge those together, as Shib did, it's undefined, which is
why I think 2.0 should really stick with attribute push by default.

I also think (as I thought when Ping was complaining about some of this)
that people want deployment-specific rules embedded into these profiles, and
that's wrong. Deployment profiles go on top of the technical profile. If
that means implementers have more work to do to anticipate needs, well,
that's the point of competing on features.

But in all the past cases you've described, your problems seem to stem from
an inability to get the right logic into the IdP and from separating things
into different domains that could be in one and so would share knowledge of
identifiers. It wasn't really in scope for SAML to figure out how
identifiers are exchanged via something other than SAML, for example. But
profiles that cross technologies could and should do so.

-- Scott