REVISED Issue Group 12, yet again.

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

OK, here we go again, based on the discussion during the 03/28 conference
call.

I've taken most of the previous questions and rolled them into the
introductory text. I've tried to capture the discussion on possible
resolution, along with the comments from ballots, in the suggested
resolutions. I've also reworded things to refer only to confidentiality
protection; I think [R-Signature] already addresses message integrity.

Please please please comment quickly, if you have comments, so that Darren
can include this in next week's ballot without generating another round of
debate. In particular, there are a couple of places where I suggest possible
limits on how much detail we put in the Use Case document.

Note that my use of 'should' in the proposed requirements matches that in
the existing requirements list in Strawman 3.

 - irving -

------------------------------------------------------
Issue Group 12:

UC-9-02:PrivacyStatement addresses the
importance of sharing data only as needed between security zones (from
asserting party to relying party). However, it is also important that data
not be available to third parties, such as snoopers or untrusted
intermediaries.

One possible solution for protocol bindings to define secure channels
between
relying party and asserting  party. Another is specifically encrypt the SAML
data, so that it is protected whether or not the channel is secure, and can
also be stored securely outside of the protocol binding (for example, in a
cache or as a cookie).

If confidentiality protection is specified both within the SAML message
format and within protocol bindings, deployments can choose the appropriate
solution. For example, SAML messages within encrypted S/MIME documents may
not need message-level protection, while SAML messages passed as HTTP
cookies do.

The issues addressed here also relate to [R-Signature],
ISSUE:[UC-13-02:EfficientMessages], ISSUE:[UC-13-03:OptionalAuthentication],
and ISSUE:[UC-13-04:OptionalSignatures]. In particular, we would be
contradicting ourselves if we voted that confidentiality
protection is required without exception, and at the same time voted for
option 1 on any of the UC-13 issues listed above. The point raised in the
UC-13 issues is that within a protected security domain where
confidentiality
protection is not a concern, requiring encryption could introduce key
management and performance issues that could otherwise be avoided.


This issue breaks down into several decisions:

Should confidentiality protection of SAML messages be
required, optional, or unsupported?

Should confidentiality protection be provided by the protocol
binding or within the SAML message format?

What (if any) encryption method should be used now?

What (if any) encryption method should be used once XML Encryption is
a published standard?


----------------------------------------------------------------------------

ISSUE:[UC-12-01:Confidentiality]

Add the following requirement:

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

Proposed Solutions:

1) Add [R-Confidentiality]
2) Do not add [R-Confidentiality]

----------------------------------------------------------------------------


IRVING'S NOTE: We could just stop here, and leave the rest of the details to
the Core Assertions, Bindings and Security Considerations groups.



----------------------------------------------------------------------------

ISSUE: [UC-12-02:AssertionConfidentiality]

Proposed solutions; choose one of:

1) Add the requirement:
[R-AssertionConfidentiality] SAML should define a format so that individual
SAML assertions may be encrypted, independent of protocol bindings.

2) Add the requirement:
[R-AssertionConfidentiality] SAML assertions must be encrypted, independent
of protocol bindings.

3) Add a non-goal:
SAML will not define a format for protecting confidentiality of individual
assertions; confidentiality protection will be left to the protocol
bindings.

4) Do not add either requirement or the non-goal.

In either case, Use Cases should be edited to call out this requirement
where appropriate.

----------------------------------------------------------------------------
-

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.

----------------------------------------------------------------------------

IRVING'S NOTE: I wouldn't mind if ISSUE:[UC-12-03:EncryptionMethod] was left
out of the use cases document, and left up to the other subcommittees. It's
really more of a design issue than a requirement.

ISSUE:[UC-12-03:EncryptionMethod]

If confidentiality protection is included in the SAML assertion format (that
is, you chose option 1 or 2 for ISSUE: [UC-12-02:AssertionConfidentiality]),
how should the protection be provided?

Note that if option 2 (assertion confidentiality is required) was chosen for
UC-12-02, resolution 1 of this issue implies that SAML will not be published
until after XML Encryption is published.

Proposed resolutions; choose one of:

1) Add the requirement:
[R-EncryptionMethod] SAML should use XML Encryption.

2) Add the requirement:
[R-EncryptionMethod] Because there is no currently published standard for
encrypting XML, SAML should define its own encryption format.
Edit the existing non-goal of not creating new cryptographic techniques to
allow this.

3) Add no requirement now, but include a note that this issue must be
revisited in a future version of the SAML spec after XML Encryption is
published.

4) Do not add any of these requirements or notes.