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: PROPOSED TEXT: Issue Group 12


Here is another cut at Issue Group 12. I added some new possible
resolutions, based on discussion during the Mar. 21 conference call. I'll
let you guess which ones I put in just to make sure they got voted down...

 - 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 implementors is to use secure channels between
relying party and asserting  party. Another is specifically encrypt the SAML
data, either with a shared secret or with public keys.

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 for ISSUE:[UC-12-01:Confidentiality]
option (a) (C&I protection required) and at the same time voted for option 1
on any of the UC-13 issues listed above.


This issue breaks down into several decisions:

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

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

What encryption method should be used?


----------------------------------------------------------------------------
--
ISSUE:[UC-12-01:Confidentiality]

Choose one of the following:

a) Confidentiality and integrity (C&I) protection of SAML messages is
required.

b) C&I protection is optional (but encouraged).

c) C&I protection is unsupported.

----------------------------------------------------------------------------
--
ISSUE: [UC-12-02:ConfidentialMessages]

Choose one of the following:

a) C&I protection shall be specified as part of the SAML message format.

b) C&I protection shall be specified as part of each protocol binding.
Each binding must include a description of how the confidentiality and
integrity of SAML messages can be protected within that binding. Examples:
S/MIME for MIME, HTTP/S for HTTP.

c) C&I protection shall be specified both within the SAML message format and
within protocol bindings. Deployments can choose the appropriate solution.
For example, SAML messages within S/MIME documents do not need message-level
C&I protection, while SAML messages passed as HTTP cookies do.

----------------------------------------------------------------------------
--
ISSUE:[UC-12-03:EncryptionMethod]

If C&I protection is included in the SAML message format, how should the
protection be provided? Choose one:

a) Integrity protection shall use either XML DSIG or, when the specification
is ready, XML Encryption (http://www.w3.org/Encryption/2001/).
Confidentiality protection shall use XML Encryption when it is ready.

b) SAML shall define an interim format for message encryption until XML
Encryption is ready, and then switch.

c) SAML shall define its own format for message encryption
--------------------------------------------------------------------------


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


Powered by eList eXpress LLC