They largely boil down to questioning alternate interpretations of the
syntax (allowing for Ron's point about the language used to describe what it
is that we mean here).
From: Cahill, Conor P [mailto:cono...@intel.com]
Sent: Tuesday, January 17, 2006 7:34 AM
Subject: [saml-dev] Constrained delegation
I took a look at this specification and walked away with a number of
* It seems to me that all uses of SAML assertions are delegation (even
in the browser SSO profile the browser is essentially a delegate for the
principal) so what does this particular profile add (e.g. what is the added
value of the AudienceRestriction URI added to the assertion that otherwise
had h-o-k mechanism with an ID in the subject confirmation)?
* If there is some value in this profile, why is it restricted to
h-o-k and not permitted for other confirmations as well (there are many
circumstances where a bearer token would be more than sufficient to provide
adequate protection for the transaction)?
* The profile allows for multiple delegates ("Each Delegate...") -- I
think there should be some caution in there about the potential privacy
impacts of allowing multiple delegates on a single assertion as the
NameIdentifyer at the relying part (encrypted or not) would be visible to
the delegates and potentially usable as an identifier (even the encrypted
form can be an identifier) to use in back-door collusion.
* The use of an AudienceRestriction to indicate this profile seems a
shoe horn solution to get URI into the existing spec defined elements as
this isn't actually listing a restricted audience, but in fact signalling
some interpretation of the fields.
* Looking over the Processing rules at the Relying Party, it seems
that the only rule that is specific to this profile is that you are saying
the assertion MUST contain an ID for the sending entitity. (the rest of the
rules already apply if such information is in the assertion anyway. So it
would seem that the mere existince of such IDs is a firm indication that
delegation is taking place.