[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Encryption Usecases and Requirements
Hopefully this brief message will be sufficient to outline the usecases and requirements for encryption in SAML 2.0. Comments are requested. Usecase #1: Provide confidentiality of all the information in all the statements in a SAML Assertion. The purpose might be to preserve individual privacy or to protect individual or corporate intellectual property via secrecy. Usecase #2: Provide confidentiality of the Name Identifier element. This usecase is identified in "Name Identifier Profiles and Management." This usecase requires that the encrypted Name Identifier be Schema-valid, so that an intermediary can process the entire Assertion syntactically without being able to decrypt the value. It is not clear if the requirment is to encrypt the element or just the value. Usecase #3: Provide confidentiality of an element value containing a secret, such as a password or secret key. The elements most likely to be encrypted in this usecase are SubjectConfirmationData, ds:KeyInfo, Attribute and AttributeValue. (Assuming the Attribute contined some kind of secret.) Since the information in the Assertion may be retained for some time and used repeatedly, it is not a requirement that the encryption format provide protection against replay. In other words, a party making use of an encrypted secret should decrypt it and then employ a replay protection mechanism specified elsewhere, if available, in using the value for the purposes of Authentication. Usecase #4: Provide selective confidentiality protection of some of statement contents. The motives are the same as in #1, but for some reason it is desired to protect only portions of the statements. Note that this usecase and #3 imply that distinct portions of statements may be protect with distinct keys, so that they may be accessable to distinct receiving parties. Requirements: Encryption of all or any portions of statements. Encryption based on XML Encryption. Encrypted data remains schema-valid. Signature if present, is always applied before any encryption. Non-requirments: Ablity to encrypt Assertion header information. Ability to determine data to be decrypted without parsing entire assertion. Ability to encrypt requests or responses (Use TLS). Ability to perform decryption of selected elements without retaining the entire assertion. (This may turn out to be possible, but it is listed as a non-requirement. Open questions: Is a mechanism required to specify the decryption key other than what is provided by XML Encryption? Should we profile XML Encryption to eliminate some options? Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]