Shibboleth Developers

["Scott Cantor" <>]

> Sorry, I don't get that at all from reading the spec.  As I've said
> before, the notion of IdP Proxy is underspecified in SAMLCore.

Just because it doesn't solve your use case doesn't mean it's
underspecified.

> I'm trying to fill in the holes here.  Evidently you want to fill in the
> holes with something else, and that's fine, but I don't know it is.

There are no holes for the use case that it was designed to address, which
is mainly about moving between trust domains. I'm just saying that if you're
proposing something different, for a different use case, using a different
name might be wise. The rest is a side discussion about the specifics of
your proposal.

> For instance, it doesn't make sense for an IdP Proxy to repackage an
> eduPersonAffiliation attribute asserted by a campus IdP.

Attributes are out of scope of SSO. They are considered completely
orthogonal and always have been. I understand your point, but your attempts
to solve it overlook some things, IMHO.

But I'm not convinced that "it doesn't make sense". Proxies are often used
to repackage information like that. Relying on proxies necessarily
compromises end to end policy in all kinds of ways anyway.

> The IdP Proxy is not authoritative for that attribute or any other
> attribute asserted by the campus IdP for that matter.  It seems the
> relying party must be able to distinguish between attributes for which the
> IdP Proxy is authoritative and other attributes asserted further up in the
> chain.

That presumes a relationship between the original IdP and the SP, and IdP
proxying in SAML assumes that no such relationship exists. That's the entire
reason for doing it. It is *not* about attribute aggregation.

More importantly, leaving SAML's proxying profile out of this, composiing
this sort of aggregation with SSO simply doesn't work. You end up in the
general case with expired assertions that are invalid for use by the end of
the chain. Putting them in Advice is a bit of a dodge, since I can ignore
them and still accept the outer assertion, but that doesn't help me use the
stuff in Advice if you're expecting me to, unless I just ignore assertion
validity.

It may sound strange coming from me, but I think attribute aggregation is
better done by the relying party. That's partly why I think ID-WSF is
necessary. It supplies identity mapping, token issuance, and cross-domain
data access for relying parties.

In an attempt to reuse a lot of existing profile logic, you're trying to use
SSO as is, and I think that's impossible without, at a minimum, extending
the content of the original assertion. That's theoretically doable with 2.0,
but it's impossible with 1.1.

-- Scott