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: 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
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 (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]

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:EncryptionNow]

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

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

ISSUE:[UC-12-04:EncryptionLater]

When the XML Encryption standard is published:

a) SAML shall continue to use the C&I method specified in
ISSUE:[UC-12-03:EncryptionNow].

b) SAML shall be revised to use XML Encryption.

Choose one option from each set of alternatives.


ISSUE:[UC-12-01:Confidentiality]

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]

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:EncryptionNow]

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

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

ISSUE:[UC-12-04:EncryptionLater]

a) SAML shall continue to use the C&I method specified in
ISSUE:[UC-12-03:EncryptionNow].

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