RE: [saml-dev] Constrained delegation

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

> *	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)?

At this point, discussion is probably more suited to the SSTC list, but...

I disagree that SSO is delegation. Not in the sense that it was ever used in
a security discussion that I've been involved in. Until the human/computer
interface is part of the security architecture, I think the browser *is* the
principal for the purposes of those sequence diagrams.

As for the point of the URI (which as I noted elsewhere I'd be happier
seeing as a confirmation method URI), it's to clearly indicate the meaning
of the SubjectConfirmation. I can use SC to mean anything I want. We had a
long thread on this list about it. It doesn't mean anything specific until
there's a profile defined that explains what it means for a given use case.

The point of the profile is to clearly define exactly what kind of
"association" is intended between the attesting party and the subject. As
one example, if you have a NameID inside there that doesn't happen to match
the Subject NameID, that doesn't imply delegation to me. It could just be
alternate names for the same entity. Here, the profile says explicitly they
aren't the same.

> *	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 point of the profile is to establish a verifiable delegation
relationship. I don't think Bearer can't do that. Or at least not in a way
that adds any value to the relying party.

> *	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.

There was some language in the original document that led to the draft that
needs to be added back. Of course, not every scenario requires privacy,
leaving aside that IP address already is a correlation handle.

One of the problems is that some use cases will never survive multiple round
trips to obtain a bunch of independent asserions. Too many signatures by
far. The profile just tries to allow for use cases where a single token
can't be avoided.

> *	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.

I responded to this issue on the SSTC list. That is, IMHO, the original
purpose of Audience, but I personally would be just as happy if not more so
with a new SC Method.

> *	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.

I disagree with that, but if one were to take that interpretation, then I
would suggest that the alternative to this profile is to add errata to core
that says outright that if there's an identifier present, then delegation is
taking place.

I would be fine with that, since it flat out defines HoK with an ID as
exactly what I'm trying to define. All I'm trying to do is help people
understand what they're supposed to put in an assertion if they want to do
something specific. I think you'll get serious push back if you claim that
that is self-evident at this point from core.

-- Scott