[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Voting Results - Groups 2, 3, 4, 10, 12, and 13
The ballot comments and voting results are attached. Please review the voting results doc to make sure I captured your votes appropriately. Here's what passed: ISSUE:[UC-2-01:AddPolicyAssertions] 2. Maintain the non-goal, leave out the requirement. ISSUE:[UC-3-03:Logout] 1. Add this requirement to SAML. ISSUE:[UC-3-05:SessionTermination] 1. Add this requirement to SAML. ISSUE:[UC-4-02:AttributeAuthority] 2. This issue is adequately addressed by existing use cases and doesnot require further elaboration within SAML. ISSUE:[UC-4-03:PrivateKeyHost] 3. This issue has been adequately addressed elsewhere; there is noneed for any additions to the use-case document. 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. ISSUE:[UC-10-01:Framework] 2. Leave the extensibility requirement. ISSUE:[UC-10-06:BackwardCompatibleExtensions] 1. Add requirement [CR-10-06-BackwardCompatibleExtensions]. ISSUE:[UC-12-01:Confidentiality] 1) Add [R-Confidentiality] 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. ISSUE:[UC-13-05:SecurityPolicy] 2. Leave this requirement out of use case and requirements document. Darren Platt Principal Technical Evangelist Securant Technologies 345 California St., 23rd Floor San Francisco, CA 94104 tel - (415) 263-4976 fax - (415) 764-4949 http://www.securant.com/ -----------------------------
Voting_Results_Groups_2_3_4_10_12_13.doc
Title: Company
|
*************** * Group 2 **************** Prateek: I am proposing we keep 2-02, 2-03, 2-05 and 2-08 mostly in the spirit of keeping some example service-to-service interactions within the document. ISSUE:[UC-2-01:AddPolicyAssertions] Marlena: (2) I think we should leave policy expressions to XACML. ISSUE:[UC-2-02:OutsourcedManagement] ESP: (1) I think this is a reasonable use case scenario, it gives a good illustration of a great application of SAML, and it especially calls out the firewall/proxy issue. Marlena: (2) This use-case's salient points are already covered in other accepted use-cases. Ahmed: (2) Note: This use case goals aee covered previous use cases already approved. ISSUE:[UC-2-03:ASP] Marlena: (1) 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] Marlena: (1) 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. RLBMorgan: (1) 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). JHodges: (1) it's describing things at a fairly high level of abstraction and isn't already covered in the present doc (draft-sstc-use-strawman-03.html). However, I (also) feel that addressing this sort of scenario is a lower priority than the "web-browser sign-on scenario(s)". ISSUE:[UC-2-06:EMarketplaceDifferentProtocol] Marlena: (2) Redundant (wrt use-cases) with EMarketplace. Irving: (1) Since use cases aren't normative, we can throw them all in for now and decide later if some of them are too hard to support. RLBMorgan: (2) Given that transports aren't specified in UC-2-05, this case is already covered there. ISSUE:[UC-2-07:MultipleEMarketplace] Marlena: (2) Redundant (wrt use-cases) with EMarketplace. RLBMorgan: (2) Cascading two instances of UC-2-05 doesn't appear to add any new requirements. ISSUE:[UC-2-08:ebXML] Marlena: (2) 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). Irving: (1) We really must support ebXML. RLBMorgan: (2) Not well enough defined to vote for. JHodges: (2) needs work. specific mention of "DN" way too deep a level for this doc (draft-sstc-use-strawman-0x). ************ * Group 3 ************ Hal: I am voting for these reluctantly because I feel that this will add complexity throughout SAML. For example, in a session environment it will NEVER be possible to use an assertion without checking with the session authority to see if the session has been killed. SAML will have to provide the means to determine if some online service must be consulted or if the assertion can be used as is. I am concerned that the greater complexity will delay both agreement on SAML and deployment. I suggest we keep an open mind on dropping this once we see how complex the design is. Ahmed: Generally, I believe that session management would pose a difficult scenario to comply. However, I do see a need for application level session management. The concern I have is can we come out with a simple use case required in SAML 1.0 and deal with complex use cases in SAML v. 2.0. E.g., a simple logout could be useful in current timeframe. Prateek: There is no question that adding session semantics complicates the design of SAML. At the same time, there is a lot of interest in supporting some form of inter-site session model. From an end-user viewpoint, single-sign on does not provide quite enough functionality; support for inter-operable single sessions is also needed. RLBMorgan: 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. JHodges: overall rationale: for the level of abstraction appropriate in draft-sstc-use-strawman-0x, I think we need to only expand the existing requirement.. [R-UserSession] SAML shall support web user sessions. ..as-needed. Also, many of the below detailed features ought to be expressed as "SHOULD" or "MAY" clauses in the so-edited [R-UserSession], not as "MUST"s. ISSUE:[UC-3-03:Logout] Marlena: (2) 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.) Irving: (1) I'm not happy with the explicit "message format" in the requirement; I think whether a message is needed or not is a protocol design decision. ISSUE:[UC-3-05:SessionTermination] Irving: (1) As with the previous issue, I think that if we support sessions we must support timeout, but we shouldn't specifically require a message format. ISSUE:[UC-3-9:Destination-Time-In] Irving: (2) I'd be happy if we come up with a design that supports this, but I don't want to require it for SAML 1.0 *************** * Group 4 *************** ISSUE:[UC-4-01:SecurityService] JHodges: (2) the term "security service" is used throughout draft-sstc-use-strawman-03 without being clearly defined. We should do so. ISSUE: [UC-4-02:AttributeAuthority] Marlena: (1) 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. RLBMorgan: (2) 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. JHodges: (2) this issue is a result of terminological muddiness in draft-sstc-use-strawman-03 et al. draft-sstc-use-strawman-03 needs to be normalized with draft-sstc-use-domain-03. [the latter perhaps should be incorporated into the next rev of the former] ISSUE:[UC-4-03:PrivateKeyHost] Marlena:(3) 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. JHodges: (3) this is outta scope and is already being addressed elsewhere (tho some SSTC folk are involved) see.. http://www.ietf.org/html.charters/sacred-charter.html http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-scenarios-00.txt Securley Available Credentials; Speaker - Magnus Nystrom http://www.appcluster05.com/images/123/stamon11.pdf ************ * Group 10 ************ ISSUE:[UC-10-01:Framework] RLBMorgan: (1) Obviously it needs to be clarified. We will be motivated to clarify *what* extensibility is required if we remove and rework it. JHodges: (2) but we need to extensively re-work it. ISSUE:[UC-10-02:ExtendAssertionData] Marlena: (2) 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. Irving: (2) This is a design decision to implement the general extensibility requirement. RLBMorgan: (2) This is not the clarification that is needed. There must be a framework for adding well-defined extensions. ISSUE:[UC-10-03:ExtendMessageData] Irving: (2) Another design decision. ISSUE:[UC-10-04:ExtendMessageTypes] RLBMorgan: (2) 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] RLBMorgan: (2) Same as UC-10-04. ISSUE:[UC-10-06:BackwardCompatibleExtensions] RLBMorgan: (1) Given that extensions are defined by not-yet-completed requirements, this is a reasonable thing to say about them. JHodges: (1, sorta) this actually needs to be mixed-into the [R-Extensible] requirement statement. ISSUE:[UC-10-07:ExtensionNegotiation] Hal: (3) I don't think SAML should do this, but I think the final decision should be a matter of design not requirements. RLBMorgan: (1) This is necessary if extensibility is to be done at all. JHodges: (1, sorta) this actually needs to be mixed-into the [R-Extensible] requirement statement. I feel that extension negotiation is a "MUST" if one's protocol supports the notion of extensions. ************** * Group 12 ************** ISSUE:[UC-12-01:Confidentiality] ESP: (1) I have a lot of trepidation about this one, since I believe that it's difficult to build in to SAML. But at the same time it's an important principle, and I am having a hard time having us NOT apply it. The requirement is general enough that it could be applied at the protocol bindings level or as encryption of assertions or messages without a change. Although I can see cases where in-the-clear SAML data would be useful, in general I believe this is the right choice. Marlena: (2) 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. JHodges: (1) but the term "SAML data" is vague and undefined. ISSUE: [UC-12-02:AssertionConfidentiality] ESP: (3) We have to call it one way or the other. Unless we build our own, apply a non-XML encryption mechanism, or wait for XML-Encryption -- none of which are very tasty. RLBMorgan: (1) Regarding the readiness of XML Encryption, it's OK to state a requirement that our initial design may not be able to meet. JHodges: (4) rationale: redundant ISSUE:[UC-12-03:EncryptionMethod] RLBMorgan: (4) This is design-time decision-making. *************** * Group 13 *************** Prateek: My approach here is to go with the more specific requirements as it isnt clear to me that the more "abstract" requirements can be "met" in any verifiable way. ISSUE:[UC-13-01:Scalability] Marlena: (a) 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. RLBMorgan: (2) I should have written defensible text on this, but I didn't. ISSUE:[UC-13-02:EfficientMessages] Marlena: (2) Among the best pieces of design advice I've ever gotten was "optimize later". :-) RLBMorgan: (1) 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. JHodges: (1) I suppose it's worth stating explicitly. ISSUE:[UC-13-03:OptionalAuthentication] RLBMorgan: (2) 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-05:SecurityPolicy] Marlena: (2) 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] Hal: (3) I favor the use of references (values with no inherent semantics) vs. compressed, encrypted assertions, but I think this is an engineering decision, not a requirement. Irving: (3) This decision belongs to the Bindings group. RLBMorgan: (3) 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. JHodges: (3) "reference" is undefined and vague and way too deep into design-time detail.Title: ***************
|
*************** * Group 2 **************** Prateek:
I am proposing we keep 2-02, 2-03, 2-05 and 2-08 mostly in the spirit
of keeping some example service-to-service interactions within the
document. ISSUE:[UC-2-01:AddPolicyAssertions] Marlena:
(2) I think we should leave policy expressions to XACML. ISSUE:[UC-2-02:OutsourcedManagement] ESP:
(1) I think this is a reasonable use case scenario, it gives a good illustration
of a great application of SAML, and it especially calls out the
firewall/proxy issue. Marlena:
(2) This use-case's salient points are already covered
in other accepted use-cases. Ahmed:
(2) Note: This use case goals aee covered previous use cases already approved. ISSUE:[UC-2-03:ASP] Marlena:
(1) 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] Marlena:
(1) 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. RLBMorgan:
(1) 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). JHodges:
(1) it's describing things at a fairly high level of abstraction and isn't
already covered in the present doc (draft-sstc-use-strawman-03.html). However,
I (also) feel that addressing this sort of scenario is a lower priority
than the "web-browser sign-on scenario(s)". ISSUE:[UC-2-06:EMarketplaceDifferentProtocol] Marlena:
(2) Redundant (wrt use-cases) with
EMarketplace. Irving:
(1) Since use cases aren't normative, we can throw them all in for now and
decide later if some of them are too hard to support. RLBMorgan:
(2) Given that transports aren't specified in UC-2-05, this case is
already covered there. ISSUE:[UC-2-07:MultipleEMarketplace] Marlena:
(2) Redundant (wrt use-cases) with EMarketplace. RLBMorgan:
(2) Cascading two instances of UC-2-05 doesn't appear to add any new
requirements. ISSUE:[UC-2-08:ebXML] Marlena:
(2) 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). Irving:
(1) We really must support ebXML. RLBMorgan:
(2) Not well enough defined to vote for. JHodges:
(2) needs work. specific mention of "DN" way too deep a level for
this doc
(draft-sstc-use-strawman-0x). ************ * Group
3 ************ Hal: I
am voting for these reluctantly because I feel that this will add complexity
throughout SAML. For example, in a
session environment it will NEVER
be possible to use an assertion without
checking with the session authority
to see if the session has been killed. SAML will have to provide the
means to determine if some online service must be consulted or if the assertion
can be used as is. I am concerned that the greater complexity will delay
both agreement on SAML and deployment.
I suggest we keep an open mind on
dropping this once we see how complex
the design is. Ahmed:
Generally, I believe that session management would pose a difficult scenario
to comply. However, I do see a need for application level session management.
The concern I have is can we come out with a simple use case required
in SAML 1.0 and deal with complex use cases in SAML v. 2.0. E.g., a
simple logout could be useful in current timeframe. Prateek:
There is no question that adding session semantics complicates the
design of SAML. At the same time, there is a lot of interest in supporting
some form of inter-site session model. From an end-user viewpoint,
single-sign on does not provide quite enough functionality; support
for inter-operable single sessions is also needed. RLBMorgan:
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. JHodges:
overall rationale: for the level of abstraction appropriate in draft-sstc-use-strawman-0x,
I think we need to only expand the existing requirement.. [R-UserSession] SAML shall support web user
sessions. ..as-needed.
Also, many of the below detailed features ought to be expressed as "SHOULD"
or "MAY" clauses in the so-edited [R-UserSession], not as
"MUST"s. ISSUE:[UC-3-03:Logout] Marlena:
(2) 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.) Irving:
(1) I'm not happy with the explicit "message format" in the
requirement; I think
whether a message is needed or not is a protocol design decision. ISSUE:[UC-3-05:SessionTermination] Irving:
(1) As with the previous issue, I think that if we support sessions we must support
timeout, but we shouldn't specifically require a message format. ISSUE:[UC-3-9:Destination-Time-In] Irving:
(2) I'd be happy if we come up with a design that supports this, but I don't
want to require it for SAML 1.0 *************** * Group 4 *************** ISSUE:[UC-4-01:SecurityService] JHodges:
(2) the term "security service" is used throughout draft-sstc-use-strawman-03
without being clearly defined. We should do so. ISSUE:
[UC-4-02:AttributeAuthority] Marlena:
(1) 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. RLBMorgan:
(2) 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. JHodges:
(2) this issue is a result of terminological muddiness in draft-sstc-use-strawman-03
et al. draft-sstc-use-strawman-03 needs to be normalized
with draft-sstc-use-domain-03. [the latter perhaps should be incorporated
into the next rev of the former] ISSUE:[UC-4-03:PrivateKeyHost] Marlena:(3)
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. JHodges:
(3) this is outta scope and is already
being addressed elsewhere (tho some
SSTC folk are involved) see.. http://www.ietf.org/html.charters/sacred-charter.html http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-scenarios-00.txt Securley
Available Credentials; Speaker - Magnus Nystrom http://www.appcluster05.com/images/123/stamon11.pdf ************ * Group
10 ************ ISSUE:[UC-10-01:Framework] RLBMorgan:
(1) Obviously it needs to be clarified.
We will be motivated to clarify
*what* extensibility is required if we remove and rework it. JHodges:
(2) but we need to extensively re-work it. ISSUE:[UC-10-02:ExtendAssertionData] Marlena:
(2) 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. Irving:
(2) This is a design decision to implement the general extensibility requirement. RLBMorgan:
(2) This is not the clarification that is needed. There must be a
framework for adding well-defined extensions. ISSUE:[UC-10-03:ExtendMessageData] Irving:
(2) Another design decision. ISSUE:[UC-10-04:ExtendMessageTypes] RLBMorgan:
(2) 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] RLBMorgan:
(2) Same as UC-10-04. ISSUE:[UC-10-06:BackwardCompatibleExtensions] RLBMorgan:
(1) Given that extensions are defined by not-yet-completed requirements,
this is a reasonable thing to say about them. JHodges:
(1, sorta) this actually needs to be mixed-into the [R-Extensible] requirement statement.
ISSUE:[UC-10-07:ExtensionNegotiation] Hal:
(3) I don't think SAML should do this, but I think the final decision should be a
matter of design not requirements. RLBMorgan:
(1) This is necessary if extensibility is to be done at all. JHodges:
(1, sorta) this actually needs to be mixed-into the [R-Extensible] requirement statement.
I feel that extension negotiation is a "MUST" if one's protocol supports
the notion of extensions. ************** * Group 12 ************** ISSUE:[UC-12-01:Confidentiality] ESP:
(1) I have a lot of trepidation about this one, since I believe that it's
difficult to build in to SAML. But at the same time it's an important
principle, and I am having a hard time having us NOT apply it. The
requirement is general enough that it could be applied at the protocol
bindings level or as encryption of assertions or messages without
a change. Although I can see cases where in-the-clear SAML data
would be useful, in general I believe this is the right choice. Marlena:
(2) 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. JHodges:
(1) but the term "SAML data" is vague and undefined. ISSUE:
[UC-12-02:AssertionConfidentiality] ESP:
(3) We have to call it one way or the other. Unless we build our own, apply a
non-XML encryption mechanism, or wait for XML-Encryption -- none of
which are very tasty. RLBMorgan:
(1) Regarding the readiness of XML Encryption, it's OK to state a
requirement that our initial design may not be able to meet. JHodges:
(4) rationale: redundant ISSUE:[UC-12-03:EncryptionMethod] RLBMorgan:
(4) This is design-time
decision-making. *************** * Group 13 *************** Prateek:
My approach here is to go with the more specific requirements as it isnt clear
to me that the more "abstract" requirements can be "met" in
any verifiable
way. ISSUE:[UC-13-01:Scalability] Marlena:
(a) 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. RLBMorgan:
(2) I should have written defensible text on this, but I didn't. ISSUE:[UC-13-02:EfficientMessages] Marlena:
(2) Among the best pieces of design advice I've ever gotten was "optimize
later". :-) RLBMorgan:
(1) 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. JHodges:
(1) I suppose it's worth stating explicitly. ISSUE:[UC-13-03:OptionalAuthentication] RLBMorgan:
(2) 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-05:SecurityPolicy] Marlena:
(2) 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]
Hal:
(3) I favor the use of references (values with no inherent semantics) vs. compressed,
encrypted assertions, but I think this
is an engineering decision,
not a requirement. Irving:
(3) This decision belongs to the Bindings group. RLBMorgan:
(3) 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. JHodges:
(3) "reference" is undefined and vague and way too deep into
design-time detail.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC