[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Analyzing cost of MTI features (WAS Minutes for 20-July 2004 SSTC con-call (official and focus call))
Nick, As suggested in the previous call by Scott, the best way to proceed is to start with ID-FF 1.2 SCR and analyze the various MTI features. So my next steps are to get a version of our conformance document out with the relevant ID-FF 1.2 SCR materials. In the interim, here a few thoughts on the relative "cost" of MTI features. One way to understand the relative complexity of an MTI feature is to ask the question: (1) Can a stateless component implement this feature? (2) Does it require the component to utilize long-term persistent storage? (3) Does it require the component to update external enterprise data stores? And so on. As this requirements list grows longer, it becomes increasingly difficult for independent components to implement the feature and claim conformance. If I am a vendor delivering an application which will consume SAML 2.0 assertions, I can probably assume access to a read-only identity store (e.g., via JNDI) but little else. As things stand such a component would not be eligible for conformance as both SP and SP Basic require support for name identifier update/termination protocols (update of an enterprise data store). In a different direction, most web access management systems restrict state to client-side cookies. Avoiding explicit retention of session state (requires long-term persistent storage) within the access management system is generally considered important for reasons of scalability. However, such a system would not obtain IdP conformance as it could not process a back-channel logout message. I believe this comment was also made by Steve Anderson during the previous conference call. Needless to say it is upto the TC decide whether these issues need to be reflected in the conformance matrix. - prateek -----Original Message----- From: Nick Ragouzis [mailto:nickr@enosis.com] Sent: Tuesday, July 27, 2004 1:39 PM To: security-services@lists.oasis-open.org Subject: RE: [security-services] Minutes for 20-July 2004 SSTC con-call (official and focus call) A follow-up to the conformance focus call topic: > - Nick: We still have the question of whether the NameID mgmt > protocols are MTI in basic [in IdP]. What's the process for > reaching resolution. What I actually asked was about criteria, not process. Something like: What's the CRITERIA we will consider in choosing between our options in this case? Our conversation gave rise to an economic criteria: Will SAMLv2.0 be meant only for the 5 largest vendors? Presumably this implies that the name id management (NIMgt) protocols present a significant hurdle to implementer resources -- in knowledge, time, or costs, for example. I wonder: How we can get more information on this? In asking around I've been unable to locate anyone who can offer any representative case study that would allow us to make the marginal analysis for the NIMgt part over the resources required to completely build and deliver WebSSO without NIMgt. Does anyone have one to offer? (Or even a rough (say) CoCoMo or FPA of either part?) Clearly if this turns out to be a significant burden over the base, then the question is answered. But if we are to admit economic criteria, then I think we are also called on to consider the wider marketplace dynamics of the decision: How is economic advantage derived, pursued and maintained in the identity space? I think in this case we'll find that putting NIMgt protocols as MTI in basic conformance offers tangible marginal advantage to the smaller players ... both among vendors and among deployers. The crux of this conclusion derives from three dynamics: 1. the usual dynamics of standards processes (smaller players derive more benefits relative to their market position); and, 2. the dynamics of identity-based economics (it is a bandwagon marketplace, where broad interlinking at the highest levels of value-add are crucial to preventing market breakdown due to forces that mandate that customers choose winners); and, 3. claims of conformance can offer advantages, but these advantages are not uniformly distributed, with deployers and the smaller vendors garnering relatively more benefits. In this way, larger players deploy the resources to implement the technology that suits their de facto architectures, and smaller players must follow ... with deployers choosing among these. If this de facto architecture does not include NIMgt protocols the smaller players (especially deployers, but also vendors) will have a significant challenge in adding NIMgt services where none already exist ... and the larger players are significantly advantaged. However, when (if) the larger players become sensitive to claiming conformance (from, say, deployer pressures), then specifying NIMgt protocols as MTI in basic will bestow on the smaller players (deployers, and vendors too) independent opportunities to offer and participate in NIMgt services. Where we admit economic criteria in conformance profile decisions, these arguments have some application to other decisions ... but the NIMgt protocols are the among the highest order of cases due to its role in interlinking. Hope this helps. :-) Best, --Nick > -----Original Message----- > From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] > Sent: Friday, July 23, 2004 09:30 AM > To: security-services@lists.oasis-open.org > Subject: [security-services] Minutes for 20-July 2004 SSTC > con-call (official and focus call) > > > Official meeting minutes compliments of Eve. Focus call > minutes compliments of Eve and Rob. > ... > - Nick: We still have the question of whether the NameID mgmt > protocols are MTI in basic. What's the process for reaching > resolution. > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave _workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]