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>]

Sorry to follow myself up, but it also occurred to me that if one looks at the current proposal, it seems to be:

- embed the end user's identifier (a NameID) into the intermediary's assertion
- add some kind of unsigned reference to a token with that identifier
- present both tokens to the service

Without addressing the question of whether that's good or bad, that is compelling evidence that there is no new SAML work to do. If you wanted to do this, you could use the DelegationRestriction condition as is, and issue the intermediary's assertion with the end user's NameID in the subject and the intermediary in the delegation condition. You could do this because the token issuer already has to know both identities based on your proposal anyway.

The other two requirement are not the business of SAML. The middle one strikes me as something similar (maybe identical?) to the WSS notion of a "supporting token". It belongs at that layer, and that leaves you free to implement any processing rules you want over how the two assertions are evaluated in combination.

So I'm even more convinced after a second read that it isn't necessary to define anything new in SAML.

-- Scott