[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