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