RE: REVISED Issue Group 12, yet again.

[Irving Reid <Irving.Reid@baltimore.com>]

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Friday, March 30, 2001 9:39 AM

> In spite of you heroic efforts, unfortunately I still have problems.

> First, and perhaps unimportantly, I think a) only Assertions need
> confidentiality protection

That was a missed edit on my part - I changed 'message' to 'assertion'
everywhere else.

> and that b) it should be possible 
> to protect only
> specific fields within the Assertion.

I'm inclined to look at that as a design issue for the Core Assertions
group, rather than something the Use Cases group should produce a specific
requirement for.

> 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. 

I have no objection to that. We need good wording for "SAML shall define a
format so that the desired information may _optionally_ be encrypted, and
conforming SAML implementations must support generating and receiving
encrypted data when desired by the 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.

While the wording on alternative 1) isn't clear about this, I had intended
the first option to cover these cases. The distinction I intended between 1)
and 2) is that in 1) protection by the binding is optional, and in 2) it is
required. I also intended by the slightly loose wording "should include a
description of how..." that the description could be "This binding doesn't
protect confidentiality. Use at your own risk."

> -----------------
> 
> 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

That's _exactly_ what I want. If only I could get the words right...

 - irving -