Marlena's votes on 2, 3, etc

[Marlena Erdos <marlena@us.ibm.com>]

My ballot with a fair number of comments. -- Marlena


****************
*  Group 2
****************

ISSUE:[UC-2-01:AddPolicyAssertions]
      2. Maintain the non-goal, leave out the requirement.

  Reason: I think we should leave policy expressions to XACML.


ISSUE:[UC-2-02:OutsourcedManagement]

  2. Do not add this use-case scenario.

  Reason: This use-case's salient points are already
covered in other accepted use-cases.



ISSUE:[UC-2-03:ASP]
1. Add this use-case scenario to the document.

  Reason: This one seems different enough that it seems
worth adding.  Maybe later we'll decide it is redundant (assuming
it gets voted in).


ISSUE:[UC-2-05:EMarketplace]
    1. The above scenario should be added to the use cases document.

   Reason: I wonder if this is really different than
other use case, but I'm not sure, so I'm saying 'yes'
to putting it in.

ISSUE:[UC-2-06:EMarketplaceDifferentProtocol]
     2. This use case scenario should not be added to the document.

   Reason: Redundant (wrt use-cases) with EMarketplace.



ISSUE:[UC-2-07:MultipleEMarketplace]
    2. The above scenario should not be added to the document.

   Reason: Redundant (wrt use-cases) with EMarketplace.

ISSUE:[UC-2-08:ebXML]
     2. Do not add this scenario.

   COMMENT:  I'd like to see the implied requirement of
retrieving attribute assertions by DN put up for a vote.
(I'd vote 'yes.')   I don't think we need the scenario
just to get at the requirement (and I think we should
keep down the size of our document to the extent possible).


*******************
* Group 3
*******************

ISSUE:[UC-3-03:Logout]
    2. Do not add this requirement to SAML.

   COMMENT: I am sympathetic to the notion
of application session management, but after a fair bit
of thought, I feel that it does not belongs in SAML.
It complicates matters a great deal.  I'm very concerned
about what this will mean to "SAML compliance".  I'd
much rather see application session management handled
separately (as in the case of XACML).
   (If I'm being ignorant about the compliance
implications I would welcome enlightenment.)

ISSUE:[UC-3-05:SessionTermination]
     2. Do not add this requirement and/or use cases.

ISSUE:[UC-3-06:DestinationLogout]
     2. Do not add this scenario or requirement.

ISSUE:[UC-3-8:DestinationSessionTermination]
      2. Do not add this scenario or requirement.

ISSUE:[UC-3-9:Destination-Time-In]
      2. Do not add this scenario or requirement to SAML.


***************
*  Group 4
***************

ISSUE:[UC-4-01:SecurityService]
1. This issue is now obsolete and can be closed as several security
services (shared sessioning, PDP-->PEP relationship)
have been identified within S2ML.

ISSUE: [UC-4-02:AttributeAuthority]
1. A use-case or use-case scenario similar to that described above
should be added to SAML.

   Reason: In the core group there was a some confusion about
the role of the PDP.  Some folks thought that the PDP validates
attribute assertions in addition to coming up with authorization decisions.
I argued that this wasn't a generally good idea as attribute validation and
an authZ decision are very different beasts. I proposed that an "attribute
validation PDP" be called out explicitly so we can avoid confusion in the
future.
   So, I'm not sure that we need to go on about the attribute authority
per se, but we do need to go on about what a resource manager (not that
this in the model :-)) does with an attribute assertion before it calls
the authZ PDP for an authorization decision.


ISSUE:[UC-4-03:PrivateKeyHost]

3. This issue has been adequately addressed elsewhere; there is no
need for any additions to the use-case document.

  COMMENT: The wording of this ballot was confusing.  Binding a payload
to an authN assertion is what the resolutions concerned themselves with
(and I don't believe we need a new use-case or requirement for this),
but the text of the issue says
"A user may allow a server to host a private key."  And the issue
name is PrivateKeyHost and not something like "BindPayload."
   These don't seem like the same thing to me.


ISSUE:[UC-4-04:SecurityDiscover]

  2.No, this extends the scope of [OSSML] too far. AuthZ in [OSSML]
should be concerned with AuthZ attributes of a principal,
    not of resources.



**************
* Group 10
**************

ISSUE:[UC-10-01:Framework]

2. Leave the extensibility requirement.


ISSUE:[UC-10-02:ExtendAssertionData]

2. Do not add this requirement.

  Reason: The core group is working on the format of
assertions and messages.  We are addressing extensibility there.
I don't believe we need a requirement on either assertion data or
messages for extensibility.  I think that the existing
extensibility requirement is adequate as is.
  BTW,  who said, "Assertions are the 'nouns' of SAML"? The
assertions I'm aware of say things like "Alice is a plumber", "Alice
can read file foo", "Alice authenticated with a name/pwd pair".
These sure seem like sentences to me.


ISSUE:[UC-10-03:ExtendMessageData]

2. Do not add this requirement.


ISSUE:[UC-10-04:ExtendMessageTypes]
2. Do not add this requirement.


ISSUE:[UC-10-05:ExtendAssertionTypes]

2. Do not add this requirement.


ISSUE:[UC-10-06:BackwardCompatibleExtensions]
1. Add requirement [CR-10-06-BackwardCompatibleExtensions].


ISSUE:[UC-10-07:ExtensionNegotiation]
3. Add neither the requirement nor the non-goal.


**************
*  Group 12
**************

ISSUE:[UC-12-01:Confidentiality]

2) Do not add [R-Confidentiality]

  Reason: Whether or nor messages are cryptographically protected is
a deployment issue. I don't see a reason to legislate a cryptographic
confidentiality mechanism if an organization deems it unnecessary.


ISSUE: [UC-12-02:AssertionConfidentiality]

1) Add the requirement:
[R-AssertionConfidentiality] SAML should define a format so that individual
SAML assertions may be encrypted, independent of protocol bindings.


ISSUE: [UC-12-03:BindingConfidentiality]
1) [R-BindingConfidentiality] Bindings SHOULD (in the RFC sense) provide a
means to protect SAML data from observation by third parties. Each protocol
binding must include a description of how applications can make use of this
protection. Examples: S/MIME for MIME, HTTP/S for HTTP.


ISSUE:[UC-12-03:EncryptionMethod]

3) Add no requirement now, but include a note that this issue must be
revisited in a future version of the SAML spec after XML Encryption is
published.


***************
*  Group 13
***************

ISSUE:[UC-13-01:Scalability]

 Abstain.

 COMMENT: Of course SAML should allow for scalable implementations!
This doesn't seem like a 'requirement' however.  I'm not sure though
so I'm abstaining.


ISSUE:[UC-13-02:EfficientMessages]
    2. Leave this requirement out of use case and requirements document.

   COMMENT: Among the best pieces of design advice I've ever gotten was
"optimize later". :-)


ISSUE:[UC-13-03:OptionalAuthentication]
   1. Add this requirement to the use case and requirements document.

ISSUE:[UC-13-04:OptionalSignatures]
   1. Add this requirement to the use case and requirements document.


ISSUE:[UC-13-05:SecurityPolicy]

   2. Leave this requirement out of use case and requirements document.

   COMMENT: The proposal is 'motherhood and apple pie' but as
a 'requirement' it is far too loose IMO.  An enumeration of
specific "common institutional policies" that SAML should support would
be good candidates for requirements.


ISSUE:[UC-13-06:ReferenceReqt]
   1. Replace [R-Reference] with these requirements.