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: question on BALLOT: Issue Group 12

I'm having a hard time with the items as stated.
Would you consider introducing the notion of persistent confidentiality and
message confidentiality?
In this way we could include specifying both a way to use XML encryption
when it becomes available
(I would see this as "persistent confidentiality") and express message
confidentiality as a protocol binding.
Also can we separate integrity and confidentiality?


Irving Reid <Irving.Reid@baltimore.com> on 03/27/2001 01:01:40 AM

To:   "'security-use@lists.oasis-open.org'"
Subject:  BALLOT: Issue Group 12

I've updated the final set of options, about encryption method, along
the lines of what David Orchard suggested. The revised issue list is
the main body of this message; the ballot is attached. If you think
this needs further discussion, speak up quickly. Otherwise, send your
completed ballot to the list.

 - 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

One possible solution for implementors is to use secure channels between
relying party and asserting  party. Another is specifically encrypt the
data, either with a shared secret or with public keys.

The issues addressed here also relate to [R-Signature],
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
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 (if any) encryption method should be used now?

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



Choose one of the following:

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

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:

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



If C&I protection is included in the SAML message format, how should the
protection be provided now (that is, before XML Encryption is available)?
Choose one:

a) Integrity protection shall use XML DSIG, and confidentiality
protection shall not be available.

b) SAML shall define its own format for message encryption or use
some existing encryption method other than XML Encryption.

c) SAML shall not be published until XML Encryption is a published



When the XML Encryption standard is published:

a) SAML shall continue to use the C&I method specified in

b) SAML shall be revised to use XML Encryption.

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

Powered by eList eXpress LLC