> I know people from SAML team are not very comfortable with the use of
> "artifact" but other solution could be to send some kind of
> artifact/handle in the RADIUS response and then the SP can make use of
> this to request the SAML assertion to the home idP (SOAP binding). I
> think this solution was proposed by Josh in the TNC working group, or
> maybe i'm wrong?

The problem with using artifacts is that they have to be issued/shared with
the component that's resolving them, or a lot of information has to be
communicated via the artifact by defining a new, longer, differently
structured artifact format.

> I also understand that the main discussion is how to authenticate the SP
> in order to be able to request end user attributes from her home domain.
> I assume that if both SP and idP belongs to the same "federation" there
> should not be any problem, because they can make use of the trust
> mechanism established by the federation, usually a PKI-based hierarchy
> or trust-anchor infrastructure. So, do you have in mind to describe a
> solution outside the "federation" scenario?

That issue is the bulk of the last thread you're responding to.

> Dear Scott, like one of the main experts in SAML you are, I would
> appreciate to know a bit more about the reasons about this reticence to
> allow SPs to make use of WS-security soap queries to idPs. We (here in
> UMU) are working on other scenarios with SAML and we make use of this
> approach.

WS-Security is non-interoperable, not being maintained or enhanced by OASIS
any longer (the TC folded), implemented in few languages, and is difficult
to implement in conjunction with signature-based security because of the
lack of profiles and lazy/lousy tooling. None of the pieces of the solution
compose at the library level without extensive effort.

I would advocate it where it's necessary to comply with existing standards
and to avoid reinventing something nearly as complex, or there are material
benefits to sticking with it, and avoid it otherwise.

If it's to be used, it can be profiled into "submission" to the point that
it's implementable by mortals, but the full range of options is just too
much, and most projects aren't disciplined enough to nail down only what
they need. That's also extra work that has to be taken on or you end up with
questionable interoperability at best.

 -- Scott