Encryption Usecases and Requirements

["Hal Lockhart" <hlockhar@bea.com>]

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