[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: REVISED Issue Group 12, yet again.
In spite of you heroic efforts, unfortunately I still have problems. > Should confidentiality protection of SAML messages be > required, optional, or unsupported? First, and perhaps unimportantly, I think a) only Assertions need confidentiality protection and that b) it should be possible to protect only specific fields within the Assertion. More importantly, I think it should be required in the spec and of conforming implementations, but its use not be required in any particular deployment. ... > ISSUE: [UC-12-03:BindingConfidentiality] > > Proposed solutions; choose one of: > > 1) Add the requirement: > [R-BindingConfidentiality] Each protocol binding should include a > description of how the confidentiality of SAML data can be > protected within > that binding. Examples: S/MIME for MIME, HTTP/S for HTTP. > > 2) Add the requirement: > [R-BindingConfidentiality] Each protocol binding must ensure > that SAML data > is protected from observation by third parties. > > 3) Do not add either requirement. > > In either case, Use Cases should be edited to call out this > requirement > where appropriate. This ignores two possibilities. 1) For a given instance of a given use case there is no need to exchange data which is sensitive, for example because it is public knowledge, e.g. John Smith is a M.D. 2) The owners of a deployment may decide that the confidentially of the information can adequately be protected by alternate means, e.g. a secure network. It also occurs to me that there might be a binding for which no encryption method is available. Rather than force us to either drop the binding or invent our own method, I would prefer to address the risk in the security considerations section of that binding. ----------------- I am not sure if this means I am simply voting for making confidentiality optional in the spec. I want to direct the various subcommittees to deal with the issue and define mechanisms wherever possible, but not at the cost of either a) inventing new schemes or b) delaying the publication of SAML. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC