Shibboleth Developers

["Scott Cantor" <>]

> I don't see how adding AuthnRequest support achieves this goal.

I disagree. It achieves the goal because complying with that spec forces
authentication integration and that's what people want.

However, we're not going to do this until we have time to do a partial 2.0
implementation. We spent an hour+ discussing this on the last call.

> > @Destination (location of Shib SSO Service, aka HS)
> 
> Not sure the latter is "obvious".  In advance of WAYF/IdP discovery,
> this value is unknown.  Moreover, without signing, it seems to serve
> no purpose.

We can sign, where did I say otherwise? But the value is just based on where
you send the request. Since 99% of subsequent accesses will use a cookie to
identify the IdP to use, the discovery issue is IMHO overblown. It's a
bootstrapping issue, not an operational one. But with a WAYF, the value is
the WAYF, not the SSO service, or it would be omitted by profile. It's
something to nail down, but hardly critical.

> The point of AllowCreate is not clear (there are only two brief refs
> in the SAML 2.0 spec).  If it is tied to persistent identifiers, then
> the spec should spell this out.

It's not, it's just not that useful with any other kind, which seems clear
to me. Personally, I wanted to get rid of it. The better point of control is
the IdP, not the SP. I couldn't care less what an SP wants, as long as I can
tell my IdP what to do when it asks. But Liberty had the flag, so that's the
way it goes.

> I would say the latter is out of scope for a SAML 1.1 implementation. 
> It requires too much from SAML 2.0, I think.

Well, it's what people want. I don't know what else to say. Personally, I
don't find it compelling, but others do. As for requiring too much, it's
ForceAuthn that borders on impossible to implement. The server doesn't
control the actual challenge with many technologies, so it's a mirage.

Saying I can re-use the client "session" but not the server "session" is a
minor distinction in most cases, since the goal here is supposed to be
ensuring the user didn't just walk away from the client. Since we can't
ensure that except with "weak" authentication methods (passwords), why
bother?

-- Scott