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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


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.
> 



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