RLBob's votes on issues 11-12

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Ballot:

ISSUE:[UC-11-01:AuthzUseCase]

1. Continue to include this use case.

2. Remove this use case.

My vote:  2

Comment on UC-11-01:  It may be that it will be difficult to come to
closure on interoperability of this function, but I think it's
important to try, as at least the basic functionality is well-defined.

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

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.

My vote:  I can't vote on this, none of these are correct.  This
should be structured as adding some requirement to the doc, but it's not.

Comment:  Integrity protection is IMHO required as it's part of the
definition of an "assertion".  Confidentiality is optional.  The ability
to provide confidentiality protection regardless of bindings is the issue
here.  The next issue tries to capture this but goes into too much detail.

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

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.

My vote:  none of the above, again

Comment:  This is certainly an issue that the TC has to decide, but it
doesn't seem to me to be a UseCase-Requirements issue.  We should say
what the C&I requirements are.  How this is achieved via bindings and
new SAML formats is part of the engineering effort.

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

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.

My vote:  none of the above.

Comment:  ?!??!  These are statements about engineering decisions, not
about requirements.

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

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.

My vote:  none of the above.

Comment:  ?!??!  These are statements about engineering decisions, not
about requirements.