[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [saml-dev] Constrained delegation
Here's Conor's note from saml-dev. 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). -- Scott -----Original Message----- From: Cahill, Conor P [mailto:conor.p.cahill@intel.com] Sent: Tuesday, January 17, 2006 7:34 AM To: saml-dev@lists.oasis-open.org Subject: [saml-dev] Constrained delegation I took a look at this specification and walked away with a number of questions: * 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. Conor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]