OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

    I guess the only way to do so is to examine the relationship between 
the attesting entity, the subject of the assertion and a
     <saml:SubjectConfirmation> element. It would be helpful  we could 
establish some definitions or clarifications here, even if they
      are purely informational.

     I guess the "SenderVouches" model was a slash and burn way of 
marking an assertion as delegated. Unfortunately, it does not carry a 
confirming
     key with it and so not that helpful is many contexts.

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.

     In some cases (e.g., holder-of-key) it may also designate a 
specific key."

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.

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

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

------------
- prateek




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]