What Do You Want From Me!?
In my recent digressions on architecture, I have pointed out that the increasing effectiveness of COTS products in the resolution of architectural concerns should lead to a different approach to all specification and implementation disciplines. The question remains: "how do we go about this?" I have learned during my many lives that arguing with kings is not a wise strategy. Therefore, I will "Start at the beginning and when [I] come to the end, stop."

The beginning, it seems to me, is requirements. If we are to implement ADM, we must understand the requirements of our system as it relates to architecture. We must also understand the relationship of those requirements to others, in order to prioritize and establish assessment and mitigation strategies.

Architects have attempted to specify these requirements (often termed supplemental requirements) around reliability, security, performance, etc. In other words, we have attempted to specify the system requirements, as opposed to the business functional requirements, that must be fulfilled in order to achieve all business goals. Collectively, these requirements have driven most (but not all) of the architectural elements of the system.

All of this is well and good in isolation, yet questions arise concerning the integration of these requirements into the more useful business functional requirements of the system. These requirements are also divided into areas. These areas often correspond with business organizations such as accounting, sales, management, etc. These might be further decomposed as necessary in order to determine the best resource for elaboration.

So many ways of looking at the system, and so many experts required to elaborate them. How can we ever hope to bring them together (in any complex system) in a way that fulfills all those stakeholder needs? Remember, we have only covered requirements-- there are still a huge number of processes that must occur, each with their own stakeholder needs, before a final system is delivered.

The answer, in a nutshell, is MDSOC. By allowing the specification of each of these areas (and their constituent decompositions) as concerns, MDSOC provides a mechanism whereby the unification of the concerns can be achieved across all specification and implementation disciplines.

At this time, MDSOC is fairly immature. This is no panacea, awaiting application in order to resolve all our woes. Rather, it is a framework that I believe can be expanded upon to discover the proper processes necessary to evolve software engineering practice to the point necessary to meet the next generation's expectations.

The journey is begun. Proceeding to the end seems a deliciously enticing process, indeed.
- posted by Terry Cowart @ 8:28 AM 0 comments

 
Trust No one.
Aside from being the mantra of one of my favorite television serials of all times, the statement "trust no one" also serves as an interesting mathematical limit to the concept of authentication. Specifically, I am willing to state with some confidence that I trust, absolutely, all claims made by no one. You see, "no one" doesn’t tend to make many claims, and therefore does nothing to stretch their credibility. While seemingly nonsensical, or at best very "Zen", I urge the reader to think through this statement a little further.

As previously mentioned, the various perspectives of authentication form a multidimensional space in which the "trust" one places in an identity claim can be evaluated. That, however, is only the beginning of the problem. The next problem is to determine just how "evaluable" such a space might be. It does no good to provide a theoretical model which has no practical way of being resolved.

By demonstrating (anecdotally) that there is a definition of the upper bound (I trust, in the absolute, "no one") we have established one of the criteria of evaluability. Next, it is easy to postulate that the there is a minimum, as well: "even if I truly believed you are who you claim to be, I would place no trust in you." This, however, creates an interesting consequence: If we have a guaranteed minimum value (absolutely no trust) which we can place on an identity claim and a guaranteed maximum value (perfect trust) on another claim, then we have both upper and lower bounds on our results. This means we can normalize any evaluation result to any range of values we want: like, say, 0…1. This is an important conclusion that supports the tractability of any claim that meets these criteria. Further, if our formula is continuous, it would then be differentiable, which would facilitate the evaluation of trust over time.

How, then, do we begin to produce a formula that is able to take these various aspects and provides a useful evaluation of the identity? And how does this tie in with the concept of trust? Ah, fodder for another post.

- posted by Terry Cowart @ 12:05 PM 0 comments

 
FeliCa BohiCa?
When I spoke of NTT DoCoMo's new cell phone with embedded FeliCa technology, I posed a few questions, and mentioned that I might some day get around to answering them. While some are far too technical for such a "brief" environment as this blog, one, at least, deserves attention in the context of other posts here.

I have written before about the establishment of identity and its relationship to trust. What I have not written about (this post constitutes a preview) is the relationship of trust to value. To summarize: the amount of trust required for a set of transactions is directly proportional to the value of the transactions.

So, what is the problem with the "DoCoMo" solution? If it provides no more FeliCa based value than a single transaction, it is no better (possibly worse) than a standalone card. If it provides access to valueless additional transactions, the same logic applies. Only if the FeliCa implementation increases the value of the transactions under consideration can it truly be considered a value add.

Ah, there's the rub.

If the value increases beyond a certain threshold, then a authentication method based on nothing more than "what you have" becomes unable to support the trust required for the transaction set. Another preview: this is the exact point at which fraud becomes profitable.

I don't pretend to know what that "threshold" value is. I have read a bit about the FeliCa security model, and wouldn't personally rate it too high. It is very good for what it claims to do, but like so many other things before it, I believe this might just be stretching it beyond the point it was intended. Here's hoping that the bright folks at NTT are able to take advantage of the technology and cultural synergy in a way that lets it stretch, without breaking.
- posted by Terry Cowart @ 11:32 AM 0 comments

 
Field Test
Between training, vacation, and holidays, I have been a bit remiss in posting-- apologies to those non-existent people who need their fix.

I have posted a few times on the subject of security, especially in the area of identity, authentication, and trust. There is a movement afoot that I believe illustrates the issues quite well, so I will bring up a specific instance in that movement, and perhaps, (the muse willing), expound further on the subject in the future.

NTT DoCoMo is releasing a FeliCa phone, with the intent of enabling payments, such as public transportation fees, to be made from the phone. Termed by some (for example, MIT's Technology Review) as the early advent of ubiquitous computing, this technology does indeed open the door to a wide variety of possible usage scenarios, many of which have made their way into the general discussion of this technology.

As an exercise to the reader, I pose a number of questions. What kind of security measures are required to make this solution viable? What are the concerns? Are there any usage scenarios that cannot be appropriately secured under the proposed technology?

Some of these questions can be answered with no more information than appears in this post. Some require more research into the underlying systems. Suffice it to say that I am rather surprised by some of the industry response to this new technology-- it reeks of internet-bubble speak. But enough for now. Answers to these questions, and more "conversation" on the general topic of security, coming soon....
- posted by Terry Cowart @ 8:50 AM 0 comments