ID Maan comments:
Little puzzled with your views respect to SAML:
“It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent â€œdisappearingâ€ of the user.”
As I understand WS-Trust is a token agnostic protocol. Delegation on other hand can be essentially considered as the capability of the securty token. So, isn't WS-Trust in a way dependent on the security token capabilities to provide for delegation? In other words, if you state SAML is insufficient to solve delegation problem, so is WS-Trust protocol that uses SAML tokens?
No wonder he is puzzled. I should have been clearer. Let me try again.
We all agree the SAML token is a fine and good way of expressing sets of claims.
But beyond the token, there is the SAML protocol – one way of moving SAML tokens around.
I think the SAML protocol suffers from having a single-token design. Why?
I don't think delegation problems can be solved through a single token. Once you are expressing the identities of both a user and a delegate, you need to be able to request and convey two (or more) tokens – in the sense of integral things from separate sources. In the simplest case, one represents the user, one the delegate.
To be clear, I wasn't hitting on the SAML protocol in all its applications. I was arguing that WS-Trust, which has the ability to move and request multiple tokens simultaneously and establish relationships between them, solves the delegation problem more cleanly from an architectural point of view.
When SAML was being elaborated, before the user-centric identity wave, we saw the user as being represented by the portal service. She had no independent existence. So you didn't need multiple tokens.
Since Identity 2.0, all this has changed.