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: Contradictory requirements?

Title: Contradictory requirements?

Colleagues - Here are some excerpts from our requirements documents, with commentary ...

"[R-Bindings] ... SAML should define bindings ... to ... the following protocols: standard commercial browsers ..."

 - This suggests a "token-style" authentication scheme as described in draft-sstc-bindings-model-04.doc, Section 3.1.

"[R-Confidentiality] SAML data should be protected from observation by ... untrusted intermediaries."

 - This suggests that intermediaries may be of two types: trusted and untrusted.

"[R-Intermediaries] SAML data ... will be structured in a way that they can be passed from an asserting party through one or more intermediaries to a relying party.  The validity of the message or assertion can be established without requiring a direct connection between the asserting and relying parties."

 - This prompts a number of questions:

"Are the intermediaries referred to of the trusted or untrusted type?"  I assume that (in order to satisfy the "single-sign-on", "third-party security service" and "application chain" scenarios) the intermediaries referred to must have access to the contents of messages and assertions.  But, must the ultimate relying party trust them not to deliberately, or accidentally, impersonate the principal, or cause another browser to impersonate the principal?

The scenarios referred to in the last paragraph are written in terms of chains with a single intermediary.  But, the requirement includes the phrase "one or more".  So, should we think of the scenarios as just a special case of the more general requirement in which chains may contain many intermediaries?

If intermediaries have to be of the trusted type, then how will a relying party tell what intermediaries have handled the token and whether or not they should be trusted? 

If intermediaries may be of the untrusted type, then it seems unlikely that we will find a solution that can satisfy both the [R-Intermediaries] and the [R-Bindings] requirements.  We may have to remove the second sentence of the [R-Intermediaries] requirement.

Thoughts anyone?  Best regards.  Tim.

Tim Moses
Tel: 613.270.3183

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

Powered by eList eXpress LLC