This mail is publicly posted to a distribution list as part of a process of public discussion, any automatically generated statements to the contrary non-withstanding. It is the opinion of the author, and does not represent an official company view.
Gary
The concept of product identity has been much discussed in the product support world. Briefly, the conclusions are:
1) Anything can have multiple identifiers, each assigned by different organizations, and it is required that each organization ensure the identifiers in its context are unique.
2) Things are identified by identifier, defining organization identifier, and the identifier of the organization that that provides the organization identifier (three of these are recognised, CAGE Code, Dunn and Bradstreet and the European equivalent).
3) It may be necessary to classify identifiers as "preferred", "mandatory" etc, so that identification does not become mangled in a round trip through someone's system - and it implies that systems must therefore be able to maintain multiple identifiers.
4) In the aircraft industry, an individual component must maintain an identity throughout its life - this is complicated by the way that products are identified by product type and serial number; remanufacturing means that the product type (which is a classification code) becomes invalid.
5) Unique identifiers may include version, variant and iteration codes (see 8 below).
6) Compounds of simple products are essentially arbitrary, and tracking identifiers are decided by convention. For example, a typical pc is a configuration of hardware and software that changes over time. In big corporations, a network is a constantly changing configuration of nodes, connections and software. But, as Cardinal Newman observed, Rome is still Rome, even though most of the original has been rebuilt or replaced several times.
7) Most complex system are defined by multiple views, each being a set of independently changing configurations of subsystems in the same view, some of which may not resolve down to the level of a real individual thing. E.g. the requirement X123: The product will have a mean time to failure of 10,000 hours. (Requirements are viewed as part of the product).
8) Identify management is one component of configuration management. Consequently, the concept of identity is defined by the industrial processes that manage identity. Therefore, industries with different identification management processes will have different concepts of what is meant by identity.
One notes also:
9) SOA architectures are low level infrastructure architectures, which are (by design) neutral to the industrial processes that use them. Consequently, SOAs have nothing to say about identity management of things other than for components of the SOA.
10) EU projects, such as Trustcom have looked at the technical challenges of building chains of trust over an SOA. I don't know that they looked at the business issues. I have been investigating certification of the use of SOAs under the SIMDAT EU project. Since most of the important certification processes (eg ISO 9000, EN/AS 9004 for quality, OAIS and EN 9300 for long term maintainability of data, BIP 0008 for evidential weight) and methodologies (e.g. SABSA for security) require physical audit of the organizations involved, the problem of building a trusted identity management service will be interesting.
Sean Barker
BAE SYSTEMS - Advanced Technology Centre
Bristol, UK
+44(0) 117 302 8184
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
Recently I ran into a somewhat related issue of identifiers in the SOA/ Web services security area and the concept of "active entity", discussed for things like ad-hoc mobile environment.
SOA and web services have the trust issue of Identification and Authentication, i.e. Verifying the identity of a user, process, device etc. as a prerequisite for access to resources in an information system. I’ve just seen some general things discussed about the semantic issues and resolutions for this, but SOA seems to happily humming along as if the issue of identify will be handled OK by the proper approach to naming. Sort of like a general extension of ISO 3166-2, “Codes for the representation of names of countries and their subdivisions” to service entities, device entities etc. So you just have a single hierarchy with the nodes named….
But it is easy to imagine problems as trust relationships span multiple organizations which have different names for “active entities” and their parts and assemblies into which they are composed.
I’m wondering if anyone else has thought about the issue of semantics involved in Identity Management and what the limits of a systematic naming approach might be?
Is anybody addressing the semantic issues so that service and person identities don’t become a problem?
Gary Berg-Cross, Ph.D.
Semantic Technology
SOCoP Executive Secretary