OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[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

> 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

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.


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

Powered by eList eXpress LLC