OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: {AP-1} Generalized or specialized solution


 

{AP-1} Generalized or specialized solution

This is a common question about the design process. Should we develop a
solution that is specialized to satisfying just those requirements
identified by the Use Case sub-committee, or should we "induce" a more
general set of requirements and provide a solution for that? In the
latter case, we would "profile" the chosen design to address the
identified use cases.

The arguments are familiar. On the one hand, the specialized solution
could be more streamlined for the particular situations identified by
the Use Cases sub-committee. On the other hand, the generalized approach
may turn out to be sufficiently flexible to address a broader set of
problems, and thereby find more widespread use.

Question: which of these statements do you agree with (only one,
please)?

Answer:

1. We should develop a generalized solution as an interim step to
satisfying the specific requirements identified by the Use Cases
sub-committee.

2. We should directly address the requirements identified by the Use
Case sub-committee.


PM> One concern here is that the use-case sub-committee is providing fairly
PM>broad guidance. For example, combining an attribute authority
PM>and a PDP in a single entity hasnt been explicitly called out in the
PM>requirements, even though it is easy to argue that this is an
PM>important case in practice. Not supporting such a combination
PM>results in requiring multiple remote calls instead 
PM> of one and will create a significant barrier to SAML acceptance.
PM>
PM> Perhaps, we should add a third case to the above, in which, the 
PM> core group will propose certain use-case scenario "specializations" to
PM> the requirements group. Admittedly, this isnt orthodox practice, but
PM> it does deal with the fact that certain aspects of the messaging 
PM> structure may be key to successful SAML deployments.


- prateek


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC