[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RLBob's votes on usecase issues 2++
Here, they are, before the end of *my* day (if we do this again we should
probably set deadlines in UTC ...).
- RL "Bob"
---
****************
* Group 2
****************
ISSUE:[UC-2-01:AddPolicyAssertions]
1. Remove the non-goal, add this requirement, and refer to data in
this format as "policy documents."
2. Maintain the non-goal, leave out the requirement.
Vote: 2, leave out the requirement.
ISSUE:[UC-2-02:OutsourcedManagement]
1. Add this use-case scenario to the document.
2. Do not add this use-case scenario.
Vote: 2, do not add this scenario.
ISSUE:[UC-2-03:ASP]
1. Add this use-case scenario to the document.
2. Do not add this use-case scenario.
Vote: 2, do not add this scenario.
ISSUE:[UC-2-05:EMarketplace]
1. The above scenario should be added to the use cases document.
2. The above scenario should not be added to the document.
Vote: 1, add the scenario.
Comment: Alone among the Group 2 scenarios this one is specific. I
think it should be included so that we can discuss how it fits into
the abstract model(s) and how it can be supported; but I hope that
designing SAML support for this scenario is made a lower priority than
the web-browser sign-on scenario(s).
ISSUE:[UC-2-06:EMarketplaceDifferentProtocol]
1. Add this scenario to the document.
2. This use case scenario should not be added to the document.
Vote: 2, do not add the scenario.
Comment: Given that transports aren't specified in UC-2-05, this case
is already covered there.
ISSUE:[UC-2-07:MultipleEMarketplace]
1. Add this scenario to the document.
2. The above scenario should not be added to the document.
Vote: 2, do not add this scenario.
Comment: Cascading two instances of UC-2-05 doesn't appear to add any
new requirements.
ISSUE:[UC-2-08:ebXML]
1. Add this use case scenario to the use case and requirements document.
2. Do not add this scenario.
Vote: 2, do not add this scenario.
Comment: Not well enough defined to vote for.
*******************
* Group 3
*******************
Comment: I abstain on this group. I understand that this
functionality is in some systems and work on standardizing it is
important to some parties. It isn't functionality I'm interested in,
but if work can be done on it in such a way that Session functionality
is an optional add-on to base SAML functionality, I am not opposed to
it being done. I will suggest a requirement that Session
functionality *not* be required to support the simple sign-on case.
ISSUE:[UC-3-03:Logout]
1. Add this requirement to SAML.
2. Do not add this requirement to SAML.
Vote: Abstain.
ISSUE:[UC-3-05:SessionTermination]
1. Add this requirement to SAML.
2. Do not add this requirement and/or use cases.
Vote: Abstain.
ISSUE:[UC-3-06:DestinationLogout]
1. Add this scenario and requirement to SAML.
2. Do not add this scenario or requirement.
Vote: Abstain.
ISSUE:[UC-3-8:DestinationSessionTermination]
1. Add this scenario and requirement to SAML.
2. Do not add this scenario or requirement.
Vote: Abstain.
ISSUE:[UC-3-9:Destination-Time-In]
1. Add this scenario and requirement to SAML.
2. Do not add this scenario or requirement to SAML.
Vote: Abstain.
***************
* Group 4
***************
ISSUE:[UC-4-01:SecurityService]
1. This issue is now obsolete and can be closed as several securityservices (shared sessioning, PDP-->PEP relationship)
have been identified within S2ML.
2. This issue should be kept open.
Vote: 1, no generic "security service" definition is needed.
ISSUE:[UC-4-02:AttributeAuthority] Should a concept of an
attributeauthority be introduced into the [OSSML] use
case document? What part does it play? Should it be added in to
anexisting use case scenario, or be developed into its own scenario?
1. A use-case or use-case scenario similar to that described above should be added to SAML.
2. This issue is adequately addressed by existing use cases and doesnot require further elaboration within SAML.
Vote: 2, no specific use case is needed (though it may not have been
adequately addressed, see Comment).
Comment: Existing use cases should have their terminology aligned
with that of the Domain Model, which explicitly includes an Attribute
Authority that generates Attribute Assertions. To the extent that
existing use cases use other terminology or muddy concepts, they
should be aligned with the Domain Model, and should illustrate the
function of the Attribute Authority.
ISSUE:[UC-4-03:PrivateKeyHost]
1. A use-case or use-case scenario comprising steps (a) and (b) aboveshould be added to the use-case document.
2. A requirement for supporting "binding" between AuthN assertionsand business payloads thru digital signature
be added to the use-case document.
3. This issue has been adequately addressed elsewhere; there is noneed for any additions to the use-case document.
Vote: 3, no need to add this scenario.
Comment: This is simply out of scope. See IETF Sacred working group.
ISSUE:[UC-4-04:SecurityDiscover]
1.Yes, a service could be provided to send authorization dataabout a service between security zones. This would require some
sort of policy assertions (UC-2-01:AddPolicyAssertions).
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.
Vote: 2, do not add requirements about discovery or policy expressions.
**************
* Group 10
**************
ISSUE:[UC-10-01:Framework]
1. Remove the extensibility requirement.
2. Leave the extensibility requirement.
Vote: 1, remove the requirement.
Comment: Obviously it needs to be clarified. We will be motivated to
clarify *what* extensibility is required if we remove and rework it.
ISSUE:[UC-10-02:ExtendAssertionData]
1. Add requirement [CR-10-02:ExtendAssertionData].
2. Do not add this requirement.
Vote: 2, do not add.
Comment: This is not the clarification that is needed. There must be
a framework for adding well-defined extensions.
ISSUE:[UC-10-03:ExtendMessageData]
1. Add requirement [CR-10-03:ExtendMessageData].
2. Do not add this requirement.
Vote: 2, do not add.
ISSUE:[UC-10-04:ExtendMessageTypes]
1. Add requirement [CR-10-04:ExtendMessageTypes].
2. Do not add this requirement.
Vote: 2, do not add.
Comment: This is OK as far as it goes, but is incomplete. There must
be a framework for adding new message types, as other protocols (eg
IMAP) have.
ISSUE:[UC-10-05:ExtendAssertionTypes]
1. Add requirement [CR-10-05:ExtendAssertionTypes].
2. Do not add this requirement.
Vote: 2, do not add.
Comment: Same as UC-10-04.
ISSUE:[UC-10-06:BackwardCompatibleExtensions]
1. Add requirement [CR-10-06-BackwardCompatibleExtensions].
2. Do not add this requirement.
Vote: 1, add the requirement.
Comment: Given that extensions are defined by not-yet-completed
requirements, this is a reasonable thing to say about them.
ISSUE:[UC-10-07:ExtensionNegotiation]
1. Add requirement [CR-10-07-1:ExtensionNegotiation].
2. Add non-goal [CR-10-07-2:NoExtensionNegotiation].
3. Add neither the requirement nor the non-goal.
Vote: 1, add the requirement.
Comment: This is necessary if extensibility is to be done at all.
**************
* Group 12
**************
ISSUE:[UC-12-01:Confidentiality]
1) Add [R-Confidentiality]
2) Do not add [R-Confidentiality]
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.
2) Add the requirement:
[R-AssertionConfidentiality] SAML assertions must be encrypted, independent
of protocol bindings.
3) Add a non-goal:
SAML will not define a format for protecting confidentiality of individual
assertions; confidentiality protection will be left to the protocol
bindings.
4) Do not add either requirement or the non-goal.
Vote: 1, add the "should" requirement.
Comment: Regarding the readiness of XML Encryption, it's OK to state
a requirement that our initial design may not be able to meet.
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.
2) [R-BindingConfidentiality] Each protocol binding must always protect SAML
data from observation by third parties.
3) Do not add either requirement.
Vote: 1, bindings should so specify.
ISSUE:[UC-12-03:EncryptionMethod]
1) Add the requirement:
[R-EncryptionMethod] SAML should use XML Encryption.
2) Add the requirement:
[R-EncryptionMethod] Because there is no currently published standard for
encrypting XML, SAML should define its own encryption format.
Edit the existing non-goal of not creating new cryptographic techniques to
allow this.
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.
4) Do not add any of these requirements or notes.
Vote: 4, do not add.
Comment: This is design-time decision-making.
***************
* Group 13
***************
ISSUE:[UC-13-01:Scalability]
1. Add requirement [CR-13-01-Scalability].
2. Do not add this requirement.
Vote: 2, do not add.
Comment: I should have written defensible text on this, but I didn't.
ISSUE:[UC-13-02:EfficientMessages]
1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.
Vote: 1, add this requirement.
Comment: This may be motherhood and apple pie, but it's important to
have it stated so it's a well-known factor in design tradeoffs.
ISSUE:[UC-13-03:OptionalAuthentication]
1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.
Vote: 2, do not add.
Comment: I agree in spirit, but it's too low-level a statement.
There should be a way to capture security-considerations kinds of
concerns in our requirements doc, but there doesn't seem to be ...
ISSUE:[UC-13-04:OptionalSignatures]
1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.
Vote: 2, do not add.
ISSUE:[UC-13-05:SecurityPolicy]
1. Add this requirement to the use case and requirements document.
2. Leave this requirement out of use case and requirements document.
Vote: 1, add this requirement.
ISSUE:[UC-13-06:ReferenceReqt]
1. Replace [R-Reference] with these requirements.
2. Leave [R-Reference] as it is.
3. Remove mention of references entirely.
Vote: 3, remove the requirement.
Comment: References are a design solution to a design problem, namely
sending things via browsers. At design time this solution will come
up. The requirement of supporting browser-based communication is
captured elsewhere.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC