RE: Comments on draft-cantor-saml-sso-delegation-01

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

Before answering, let me note that I wasn't specifically submitting this as
a TC proposal, I think there would need to be consensus on specific use
cases needing work from the TC first.

Thought I'll say for the record that I do think the TC ought to *at least*
consider defining a profile for expressing simple delegation in SAML
assertions as part of its role, and that combining this with the existing
SSO profiles would be a reasonable (and simple) follow-on to that.

> 1. First, a dumb question -- How does a recipient distinguish between a 
> delegated SAML assertion and one that is not so delegated?

There'a an AudienceRestriction defined with a profile URI.

> 2. I suggest changing lines 271-273 to:
> 
>      "Method attribute set to any one of
> 
>        urn::oasis:names:tc:SAML:2.0:cm::holder-of-key, 
> urn::oasis:names:tc:SAML:2.0:cm:sender-vouches,  
> urn::oasis:names:tc:SAML:2.0:cm:bearer.

I've gone back and forth on it. I need to think about it, and whether the
rest of the pieces fit together.

> 3.  line 300
>         Is the audience element 
> (urn:mace:shiboleth:2.0:profiles:delegation) used here to signify 
> delegated use of the assertion? I guess that might answer question
>         1 above. This seems to be confirmed by lines 325-326.

Yes. It seemed the cleanest way to do it.

> 4. lines 330-331
>          I am not sure I agree with this, to me it sounds like use of 
> the delegation audience value is signalling possible delegation use (vs. 
> vanilla HoK semantics).

Yes, this is perhaps a bit unclear. How about:

"A delegation relationship in an assertion created in accordance with this
profile is expressed..."

> 5. lines 332-341, 381-383
>           Needs to extended with SV and bearer cases. I can provide some 
> text in a follow-up message.

As I say, I was specifically focusing on HoK. I don't know if there's any
reasonable way to talk about delegation with bearer or SV. In particular,
does one name the entity presenting the assertion, and if so, isn't that a
back-door HoK, since you could verify that the entity can authenticate to
you as that entity?

Basically, a NameID in SubjectConfirmation doesn't feel radically different
to me than HoK with a ds:KeyName or ds:X509SubjectName. So I wanted to just
be explicit about it.

And if you don't name the delegate in the SubjectConfirmation, then it's not
clear to me that it's delegation at all, it's just impersonation of the
subject.

-- Scott