First off, thanks for the interesting discussion.
Now, addressing your comments:
>>>>> "TM" == Tim Moses <> writes:
TM> "[R-Confidentiality] SAML data should be protected from
TM> observation by ... untrusted intermediaries."
TM> - This suggests that intermediaries may be of two types:
TM> trusted and untrusted.
I think that's a fair statement, although -really- I think the
different types of intermediaries are as follows:
1) Intermediaries that aren't SAML processors in and of
themselves. For example, a mail server, a Web proxy or a router.
2) Intermediaries that -are- SAML processors. For example, a PEP that
sends AuthZ Decision requests to a PDP, including authentication
and authz attribute assertions that it received from a third party.
I agree that perhaps the use of the term "intermediaries" in that
requirement is unfortunate in that it conflates the two ideas. And
perhaps I'm not drawing a good distinction with your trusted/untrusted
dichotomy. After all, if I send some authc assertion to a PEP, I
am trusting the PEP to use the assertion.
TM> "[R-Intermediaries] SAML data ... will be structured in a way
TM> that they can be passed from an asserting party through one or
TM> more intermediaries to a relying party. The validity of the
TM> message or assertion can be established without requiring a
TM> direct connection between the asserting and relying parties."
Let me just point out that the idea behind this was to allow two
parties to use, and reference, a third-party assertion. Another use
would be for SAML queries to go through firewalls, a queuing message
system, or what have you.
Having a messaging protocol where authentication of the sender is
dependent on (say) the IP address gleaned from the underlying
transport protocol is weak and inflexible.
~ESP
--
Evan Prodromou, Senior Architect
Securant Technologies, Inc. 415-856-9551
