Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] FW: [security-services] Public Review of SAML 2.0 Profiles

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] FW: [security-services] Public Review of SAML 2.0 Profiles


Chronological Thread 
  • From: <>
  • To: <>
  • Subject: RE: [Shib-Dev] FW: [security-services] Public Review of SAML 2.0 Profiles
  • Date: Mon, 30 Mar 2009 15:04:22 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US


I have some questions about the SAML V2.0 Condition for Delegation
Restriction Version 1.0.

Mostly I am concerned that I don't fully understand how this would be
composed. Would it be possible to include some scenarios that explain how it
could be used and demonstrate what the conditions would actually look like
for those scenarios.

For example is the following an intended scenario:

An IDP issues an assertion to an SP. The SP adds itself as a Delegate to
this assertion and then forwards it onto a RP (strips off the IDP's signature
and adds its own signature). The RP then makes a decision based on the
Delegate/IDP/Assertion Content/Signature.


Is this a scenario that is supported:

An IDP issues an assertion to an SP that includes a list of all Delegates the
IDP trusts (including that SP itself). The SP then fowards this assertion to
another RP (the SP does not alter the original assertion in any way). The RP
then makes a deicsion based on all the Delegates/IDP/Assertion
Content/Signature?


Is this a scenario that is supported:

An IDP issues an assertion to an SP that includes a list of all Delegates the
IDP trusts (this list does not include that SP). The SP will not forward
this assertion, since he is not a delegate.


Is a Delegate an issuer of assertions? Would Delegates need to appear within
the trust fabric of a federation (is this a new entity type for the SAML 2
Metadata)? Is there some part of the original SAML standards I am forgetting
that helps clarify these issues?


Archive powered by MHonArc 2.6.16.

Top of Page