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] | [Elist Home]


Subject: Re: Contradictory requirements?


First off, thanks for the interesting discussion.

Now, addressing your comments:

>>>>> "TM" == Tim Moses <tim.moses@entrust.com> 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        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551



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


Powered by eList eXpress LLC