RE: [security-services] Groups - SAML V2.0 Profile for Token Correlation (sstc-saml-token correlation-profile-v0.13.pdf) uploaded

["Scott Cantor" <cantor.2@osu.edu>]

I'm basically making two related, but separate points.

The first point is that the use case of dealing with intermediaries performing transactions on behalf of an end user system is something that we addressed at least in part by defining a normative condition type, <DelegationRestriction>, that allows the issuer of the intermediary's token to include both the end user's identity and the intermediary's identity (including a chain of them).

This doesn't explicitly reference an assertion issued to the end user, but it is designed such that the issuer of the intermediary's token is generally done only upon the intermediary satisfying some kind of proof of its rights and privileges to act for the end user. Often that includes presenting an assertion issued to the end user back to the token issuer, so it is similar to correlating the assertions, but the correlation is done by the token isser rather than by presenting both tokens to the target system.

There are also conventions one can use in the existing SAML protocol, or one can substitute WS-Trust or whatever else, to perform these token exchanges. It's not new spec work, generally, just new implementation work.

The second point I'm making is about the technical content of the proposed profile.

I think the proposal is to have a signed condition element reference the subject of the original assertion, but not sign the actual reference to the assertion. That has serious holes for security, and it's impossible to do within an assertion, because a SAML assertion is either totally signed or not signed; you can't add or remove anything to it. What you'd be talking about would be something at the WS-Security or other application layer, not SAML.

This proposal also has the problem that it wants the relying party to "rely" on the original assertion but doesn't want to required that the original assertion be valid. This is just wrong. If the original assertion is invalid, it is not appropriate to honor some kind of corelation requirement to it. It would be very difficult to understand or explain the security properties of such a system.

-- Scott