Shibboleth Developers

["Scott Cantor" <>]

> What will a typical authn response look like in Shib 2.0?  Will the
> payload still be two separate assertions or are you considering one
> assertion with two statements?

I think that ideally although the SP has to support multiple assertions, the
IdP should never actually send two except for compatibility with Shibboleth
1.3, which is a bit obscure since few people use push with that version. But
that's the only use case for it.

SAML SSO should have been fixed to require one assertion. I lost that
argument despite not a single use case for two being presented. People
complain about how complex SAML is and yet the most obvious things that
could have been done to simplify it were rejected.

In the context of your question, it's a simple reality...SAML does not
require one assertion, so the SP has to deal with the possibility it could
get ten or be explicitly non-conformant on that point. Believe it or not,
sending more than one is so stupid that I've considered it.

> Assuming the authentication response contains two separate assertions,
> will the Shib 2.0 SP continue to expose the complete response?

It effectively does not do this now, despite my best intentions, so what
you're talking about is basically a new feature and no decision has been
made on an approach yet (see the other note about it). In Java, we clearly
will expose all of it.

> I missed the discussion of the SP at the F2F so I apologize in advance
> if the following topic was covered.  Instead of exposing the response
> at the SP, why not expose the attribute assertion only (with the
> response wrapper stripped away)?  In that case, you end up with the
> same thing irrespective of push or pull.

The issue is multiple assertions. I can't expose *the* assertion because
there can be two. Or I can explicitly disallow more than one and be
non-compliant. Any votes? ;-)

> Also, why not nest the authentication assertion in the <Advice>
> element of the attribute assertion?

Because that's not SAML SSO. Unless you mean doing something after the fact
just to get it in one object, but I don't really see how that's
substantially better than a wrapper element. At least in that case you don't
break the signature on any one assertion.

-- Scott