[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