Re: [security-services] FW: [saml-dev] Constrained delegation

[Prateek Mishra <prateek.mishra@oracle.com>]

These are good points; maybe the issue is more about capturing or 
recommending certain patterns of use
vs. developing a new profile.

But before we discuss solutions, here is a question:-:

Is it important for SAML issuers and relying parties to distinguish between:

(a) A system entity that presents a SAML assertion that states "it" is 
named Joe; together with
      proof of possession..
      
        (i) SAML issuer: must ensure by some means that only Joe is 
issued this token.

        (ii) Relying party: validates proof, issuer information. May or 
may not have additional information about Joe (e.g.,
              directory entry). Provides appropriate services to Joe 
against this information.

        (iii) This is what the SAML 1.1 HoK modeled.

   (b) A system entity that presents a SAML assertion, that states it is 
named server X and is acting for Joe;
         together with proof of possession.

          (i) SAML issuer: must ensure by some means that Joe agrees/is 
aware of the issuance of the assertion to server X.

          (ii) Relying party: validates proof, issuer information. May 
or may not have other information about Joe (e.g.,
              directory entry) and server X (e.g., list of approved 
servers). Provides appropriate services to server X/Joe against this 
information.

          (iiii) This is what SAML 2.0 HoK models.


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


 

> 
>
>
>  
>
>>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).
>>    
>>
>
>Yeah, to add some additional input, I would say that anytime an 
>assertion is generated for a party that allows that party to 
>use that assertion to establish a session at a relying party 
>on behalf of a subject is, by definition, delegation.
>
>If this needs clarification, then we should clarify the parts of
>the spec that aren't clear.  
>
>I'm not sure we need anything special in the assertion to 
>identify this.
>
>I would be interested in understanding an interpretation of
>the specs that lets an assertion generated for party A to 
>use at party B with a subject that is not party A be anything
>other than delegation (of the right to represent the subject
>to party A when interacting with Party B). 
>
>Conor
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>  
>