Subject: [sacm] SWID M&A data model: ISO SWID 2015 *schema* could be an option

From: "Schmidt, Charles M." <[email-masked]>
Date: Tue, 5 Jul 2016 18:34:54 +0000

Hi all,

Regarding the Information Model used by SWID M&A, Gunnar proposed some good guidelines for what that model should look like. While there has been some discussion about whether those need to be captured in other SACM documents (i.e., the Requirements document) I haven't heard any objections to those guidelines.

As a reminder, those guidelines are:
1) The most complete (that is, closest to being able to represent the other tag types without loss of data or shoe-horning data into fields that weren't really meant for that type of data).
2) Capable of being easily extended to cover gaps as necessary. Possibly as a fork and not part of its normal maintenance.
3) Readily accessible (for example, the spec is not behind a paywall).

There was also the suggestion that, if we can find an existing structure that meets our needs, that we strongly consider adopting this rather than re-inventing our own information model.

With this noted, I want to observe (while leaving off discussions of pros and cons for the moment) that the ISO SWID 2015 *schema* (and here I'm just talking about the data model defined in the specification - not the specification as a whole) does seem to meet all those requirements:

1) It supports the encapsulation of a wide variety of information descriptive of a software product, including (but not limited to) name, version, publisher, lists of important files along with their expected sizes and hash values, lists of associated files along with their measured sizes and hashes, relations to other software products, and a unique identifier for the product.

2) The schema supports the addition of new elements anywhere, provided that these new elements use a namespace other than the one used to define the ISO 2015 SWID schema.

3) The documented schema is available here: (http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd)

I want to emphasize: I am not talking about requiring ISO SWID tags as sources for the data conveyed by SWID M&A - I don't think we can reasonably make any assumptions as to the sources of software inventory and event information that are used by SWID M&A to report information about endpoint state.

Likewise, I want to emphasize that I am not talking about adoption of the ISO SWID *specification* as a normative reference in SWID M&A. I am just talking about using the XML schema that ISO created and then made freely available as the basis of a SWID M&A data model.

So my question to the group: what else is out there that also meets the guidelines identified above?

Tony - a while ago you provided a list of other tag formats. (https://mailarchive.ietf.org/arch/msg/sacm/cwChikgJAx8fRO7YL-7jdP4_Hf4) I was not able to track down all of those formats, but it does seem like maybe about half are unique identifier schemes rather than descriptive in nature. I think identifier schemes fall afoul of Gunnar's guideline #1. Of the descriptive formats you identified, are there any that you would suggest as meeting the three guidelines Gunnar identified?

Thanks,
Charles

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 5 Jul 2016 16:02:39 -0400

I'll search through them.  SA2 is meeting next week, and
several of the major work items for Rel. 14 leverage application
identifiers and related tags.  Given the force and effect of
the global mobile specifications, they matter more than
most.

On 2016-07-05 2:34 PM, Schmidt, Charles M. wrote:
> Tony – a while ago you provided a list of other tag formats. 
> (_https://mailarchive.ietf.org/arch/msg/sacm/cwChikgJAx8fRO7YL-7jdP4_Hf4_) 
> I was not able to track down all of those formats, but it does seem 
> like maybe about half are unique identifier schemes rather than 
> descriptive in nature. I think identifier schemes fall afoul of 
> Gunnar's guideline #1. Of the descriptive formats you identified, are 
> there any that you would suggest as meeting the three guidelines 
> Gunnar identified?

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 8 Jul 2016 17:52:52 -0400

The SA2 meeting has about a dozen input
documents dealing with application identifiers
- especially for new mobile network infrastructure
and services.  S2-163518 is exemplary.

Also useful is the TEDDI tool at
http://webapp.etsi.org/Teddi/
If you enter either Application ID or
Application Identifier, you'll get links
to an array of 3GPP specifications that
define identifier schema.  These are all
open, well-versioned specs available
at permanent URIs.

Also check the specs for the OneM2M
App-ID at
http://www.onem2m.org/news-events/news/85-the-onem2m-application-identifier-app-id-registry-managed-by-atis-and-powered-by-iconectiv-provides-the-essential-means-for-interconnecting-iot-applications-2

It's worth noting that the CA/B Forum
also seems to be advancing a very promising
EV Code Signing spec that relies on an
embedded OID to convey the identifier for
getting to further tag information.

In general, it seems obvious that the
preponderance of industry approaches
to "SWIDS" rely on a minimal trusted
GUID of some kind that is then used to
query for tag info when required.  Sometimes
an associated "filter" expression is used.

The SC17 scheme seems like an interesting
theoretical exercise that at some level might
help herd the gazillion software cats out there
with a more consistent structure if it's a lookup
architecture.  An embedded approach is DOA.

A significant challenge over the years discussing
this topic in many different venues, is the lack of
interest.  Good luck.

--tony

On 2016-07-05 4:02 PM, Tony Rutkowski wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 8 Jul 2016 18:06:06 -0400

As a postscript to the previous message, one
really interesting...even exciting...possibility
arises in conjunction with the emergence of
the new  service function chaining models and
related structured templates that are emerging.
It's become a really big deal in the NFV and 5G
worlds.  Call it "next generation SWIDs." :-)
(And please stay clear of ISO).

However, you'll have to start intersecting with
other communities working on this across quite
a few different fora.  There was even a new work
item started in ITU-T SG13 this week!  There is
also a related IETF group (sfc) and some
presentations in Berlin.

--tony

---

From: Jerome Athias <[email-masked]>
Date: Sat, 9 Jul 2016 18:45:52 +0300

GUID/UUID yes.
Regarding OneM2M, if referring to ETSI resources etsiFirmware and
etsiSoftware, apparently mapped to SoftwareModules with
Device.SoftwareModules.DeploymentUnit.{i}.UUID of TR-181 Device Data
Model for TR-069, Issue 2 Amendment 8 (page 112), I would say, at this
stage, that the Data Models are not 'globally' optimized, in the sense
that while I can see it working fine for M2M, the models seem not
based on (something still not existing) an Ontology approach (which
would benefit, imho, both H2M/M2H and M2M).
(NB: I'm currently confident - focusing on the Software/Application
domain only - than the current ("abstracted") part of the XORCISM's
model [1] (where you would find GUIDs...) is better designed for
humans (and so for implementation by humans (and so for better
implementation and use))

[1] https://github.com/athiasjerome/XORCISM/tree/master/MODELS

2016-07-09 0:52 GMT+03:00 Tony Rutkowski <[email-masked]>:
> (https://mailarchive.ietf.org/arch/msg/sacm/cwChikgJAx8fRO7YL-7jdP4_Hf4) I
> was not able to track down all of those formats, but it does seem like maybe
> about half are unique identifier schemes rather than descriptive in nature.
> I think identifier schemes fall afoul of Gunnar's guideline #1. Of the
> descriptive formats you identified, are there any that you would suggest as
> meeting the three guidelines Gunnar identified?
>
>
>
>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 11 Jul 2016 16:24:42 +0000

Hi all,

Thanks for the references and discussion. This is much appreciated.

I think an important question that this is raising in my mind is "what is it that SWID M&A is reporting?" Is it a list of unique identifiers for discovered applications, or is it some descriptive information about discovered applications. The current draft of SWID M&A supports both - it can deliver identifiers and it can deliver descriptive information (currently expressed as ISO SWID tags). 

Tony - so far, what I am seeing in in your suggestions is a lot of unique identifiers, but I have not seen anything that one could use to directly encapsulate descriptive information. (I haven't read all the 3GPP documents yet, so I might very well have missed something. Of the documents I have seen so far, I see lots of use of Application ID, but I appear to have missed any spec that provides a standard descriptive structure into which that ID can resolve.) OneM2M's App-ID similarly seems to be focused on the use of unique identifiers that they manage and not on descriptive structures.

So my question to you (and the group): are you envisioning a scenario where SWID M&A delivers only unique, non-descriptive identifiers as a means of providing software inventory, but any resolution of these non-descriptive identifiers into descriptive information about an application (name, version, etc.) would require access to some registry?

Thanks,
Charles

> -----Original Message-----
> From: Jerome Athias [mailto:[email-masked]]
> Sent: Saturday, July 09, 2016 10:46 AM
> To: Tony Rutkowski <[email-masked]>
> Cc: Schmidt, Charles M. <[email-masked]>; <[email-masked]>
> <[email-masked]>
> Subject: Re: [sacm] SWID M&A data model: ISO SWID 2015 *schema* could
> be an option
> 
> GUID/UUID yes.
> > http://www.onem2m.org/news-events/news/85-the-onem2m-
> application-identifier-app-id-registry-managed-by-atis-and-powered-by-
> iconectiv-provides-the-essential-means-for-interconnecting-iot-applications-
> 2
> >

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Jul 2016 10:03:41 -0700

To take that a bit further, whether the data to communicate is unique 
software identifiers, a set of descriptive information, or an exhaustive 
list of component details (such as all assemblies and versions), that 
information is still a set of name/attribute pairs with relationships. 
Exactly the sort of thing that the SACM information model is addressing.

So is there something unique about a software inventory that requires it 
to be handled differently from all the other endpoint attributes?

--gun

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Jul 2016 16:02:13 -0400

Seems about right.

Should the acronym SWID be dropped
as irrelevant and confusing?  It would be
ideal if SACM could produce its own set
of name/attribute pairs expressed in JSON.

--tony

On 2016-07-11 1:03 PM, Gunnar Engelbach wrote:
> software identifiers, a set of descriptive information, or an 
> exhaustive list of component details (such as all assemblies and 
> versions), that information is still a set of name/attribute pairs 
> with relationships. Exactly the sort of thing that the SACM 
> information model is addressing.
>
> So is there something unique about a software inventory that requires 
> it to be handled differently from all the other endpoint attributes?
>
>
> --gun
>
>
>
>> I think an important question that this is raising in my mind is 
>> "what is it that SWID M&A is reporting?" Is it a list of unique 
>> identifiers for discovered applications, or is it some descriptive 
>> information about discovered applications. The current draft of SWID 
>> M&A supports both - it can deliver identifiers and it can deliver 
>> descriptive information (currently expressed as ISO SWID tags).
>>
>> Tony - so far, what I am seeing in in your suggestions is a lot of 
>> unique identifiers, but I have not seen anything that one could use 
>> to directly encapsulate descriptive information. (I haven't read all 
>> the 3GPP documents yet, so I might very well have missed something. 
>> Of the documents I have seen so far, I see lots of use of Application 
>> ID, but I appear to have missed any spec that provides a standard 
>> descriptive structure into which that ID can resolve.) OneM2M's 
>> App-ID similarly seems to be focused on the use of unique identifiers 
>> that they manage and not on descriptive structures.
>>
>> So my question to you (and the group): are you envisioning a scenario 
>> where SWID M&A delivers only unique, non-descriptive identifiers as a 
>> means of providing software inventory, but any resolution of these 
>> non-descriptive identifiers into descriptive information about an 
>> application (name, version, etc.) would require access to some registry?
>>
>> Thanks,
>> Charles
>>

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Jul 2016 13:23:28 -0700

Depending on what we go with, yes, using "SWID" as a generic term for 
software identity would be confusing and using some other term in the 
documentation would be helpful.

The first thing, though is to decide whether or not there is a real need 
to have a separate data model for software inventorying.  My hunch is 
not:  since there is a DM/IM that will but under control of SACM, then 
even if it doesn't currently support some data that is available in one 
of the tag systems it can simply be extended to accommodate that.

But there are people more familiar with these tagging systems than I, so 
if anybody is aware of a reason why software inventorying needs to have 
a separate data model I'd like to hear it.

--gun

On 7/11/2016 1:02 PM, Tony Rutkowski wrote:
>>> Of the documents I have seen so far, I see lots of use of 
>>> Application ID, but I appear to have missed any spec that provides a 
>>> standard descriptive structure into which that ID can resolve.) 
>>> OneM2M's App-ID similarly seems to be focused on the use of unique 
>>> identifiers that they manage and not on descriptive structures.
>>>
>>> So my question to you (and the group): are you envisioning a 
>>> scenario where SWID M&A delivers only unique, non-descriptive 
>>> identifiers as a means of providing software inventory, but any 
>>> resolution of these non-descriptive identifiers into descriptive 
>>> information about an application (name, version, etc.) would require 
>>> access to some registry?
>>>
>>> Thanks,
>>> Charles
>>>
>>>>> was not able to track down all of those formats, but it does seem 
>>>>> like
>>>> maybe

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Jul 2016 16:29:19 -0400

The other key factor here is the enormous diversity of endpoints and use cases being treated.

On Jul 11, 2016 4:23 PM, Gunnar Engelbach <[email-masked]> wrote:

Depending on what we go with, yes, using "SWID" as a generic term
for software identity would be confusing and using some other term
in the documentation would be helpful.

The first thing, though is to decide whether or not there is a real
need to have a separate data model for software inventorying.  My
hunch is not:  since there is a DM/IM that will but under control of
SACM, then even if it doesn't currently support some data that is
available in one of the tag systems it can simply be extended to
accommodate that.

But there are people more familiar with these tagging systems than
I, so if anybody is aware of a reason why software inventorying
needs to have a separate data model I'd like to hear it.

--gun

On 7/11/2016 1:02 PM, Tony Rutkowski
wrote:

Seems about right.

--tony

On 2016-07-11 1:03 PM, Gunnar
Engelbach wrote:

To take that a bit further, whether the data to communicate is
unique software identifiers, a set of descriptive information,
or an exhaustive list of component details (such as all
assemblies and versions), that information is still a set of
name/attribute pairs with relationships. Exactly the sort of
thing that the SACM information model is addressing.

So is there something unique about a software inventory that
requires it to be handled differently from all the other
endpoint attributes?

--gun

Hi all,

Thanks for the references and discussion. This is much
appreciated.

I think an important question that this is raising in my mind
is "what is it that SWID M&A is reporting?" Is it a list
of unique identifiers for discovered applications, or is it
some descriptive information about discovered applications.
The current draft of SWID M&A supports both - it can
deliver identifiers and it can deliver descriptive information
(currently expressed as ISO SWID tags).

Tony - so far, what I am seeing in in your suggestions is a
lot of unique identifiers, but I have not seen anything that
one could use to directly encapsulate descriptive information.
(I haven't read all the 3GPP documents yet, so I might very
well have missed something. Of the documents I have seen so
far, I see lots of use of Application ID, but I appear to have
missed any spec that provides a standard descriptive structure
into which that ID can resolve.) OneM2M's App-ID similarly
seems to be focused on the use of unique identifiers that they
manage and not on descriptive structures.

So my question to you (and the group): are you envisioning a
scenario where SWID M&A delivers only unique,
non-descriptive identifiers as a means of providing software
inventory, but any resolution of these non-descriptive
identifiers into descriptive information about an application
(name, version, etc.) would require access to some registry?

Thanks,

Charles

-----Original Message-----

Cc: Schmidt, Charles M. <[email-masked]>;
<[email-masked]>

<[email-masked]>

Subject: Re: [sacm] SWID M&A data model: ISO SWID 2015
*schema* could

be an option

GUID/UUID yes.

Regarding OneM2M, if referring to ETSI resources
etsiFirmware and

Device.SoftwareModules.DeploymentUnit.{i}.UUID of TR-181
Device Data

Model for TR-069, Issue 2 Amendment 8 (page 112), I would
say, at this

stage, that the Data Models are not 'globally' optimized, in
the sense

that while I can see it working fine for M2M, the models
seem not

based on (something still not existing) an Ontology approach
(which

(NB: I'm currently confident - focusing on the
Software/Application

domain only - than the current ("abstracted") part of the
XORCISM's

model [1] (where you would find GUIDs...) is better designed
for

humans (and so for implementation by humans (and so for
better

implementation and use))

The SA2 meeting has about a dozen
input

at permanent URIs.

App-ID at

2

interest.  Good luck.

--tony

several of the major work items for Rel. 14 leverage
application

identifiers and related tags.  Given the force and effect
of

most.

Tony – a while ago you provided a list of other tag
formats.

(https://mailarchive.ietf.org/arch/msg/sacm/cwChikgJAx8fRO7YL-

7jdP4_Hf4) I

was not able to track down all of
those formats, but it does seem like

maybe

about half are unique identifier
schemes rather than descriptive in nature.

I think identifier schemes fall afoul of Gunnar's
guideline #1. Of the

descriptive formats you identified, are there any that you
would suggest as

sacm mailing list

[email-masked]

sacm mailing list

[email-masked]

sacm mailing list

[email-masked]

sacm mailing list

[email-masked]

--

________________________________

Anthony
Michael Rutkowski

EVP,
Industry Standards & Regulatory Affairs

[email-masked]

+1
703 999 8270

________________________________

Yaana
Technologies LLC

542 Gibraltar
Drive

Milpitas CA
95035 USA

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 11 Jul 2016 13:39:56 -0700

Well, yeah, but when you get right down to it, this is a CMDB type of 
issue, meaning that there are two important keys that have to be addressed:

   1) How an attribute is identified
   2) How the data for that attribute is represented

Which is the same problem set that the SACM DM/IM needs to be able to 
deal with.  You can look to the efforts behind standardizing CMDBs for 
help, but there really aren't any standards there, just guidance:  that 
diversity of endpoints thing again.

Another way to think about it:  SACM is just a distributed CMDB.

--gun

On 7/11/2016 1:29 PM, Tony Rutkowski wrote:
> On Jul 11, 2016 4:23 PM, Gunnar Engelbach 
> <[email-masked]> wrote:
>
>
>     The first thing, though is to decide whether or not there is a
>     real need to have a separate data model for software
>     inventorying.  My hunch is not:  since there is a DM/IM that will
>     but under control of SACM, then even if it doesn't currently
>     support some data that is available in one of the tag systems it
>     can simply be extended to accommodate that.
>
>             I think an important question that this is raising in my
>             mind is "what is it that SWID M&A is reporting?" Is it a
>             list of unique identifiers for discovered applications, or
>             is it some descriptive information about discovered
>             applications. The current draft of SWID M&A supports both
>             - it can deliver identifiers and it can deliver
>             Tony - so far, what I am seeing in in your suggestions is
>             a lot of unique identifiers, but I have not seen anything
>             that one could use to directly encapsulate descriptive
>             information. (I haven't read all the 3GPP documents yet,
>             so I might very well have missed something. Of the
>             documents I have seen so far, I see lots of use of
>             Application ID, but I appear to have missed any spec that
>             provides a standard descriptive structure into which that
>             ID can resolve.) OneM2M's App-ID similarly seems to be
>             focused on the use of unique identifiers that they manage
>             and not on descriptive structures.
>
>             So my question to you (and the group): are you envisioning
>             a scenario where SWID M&A delivers only unique,
>             non-descriptive identifiers as a means of providing
>             software inventory, but any resolution of these
>             non-descriptive identifiers into descriptive information
>             about an application (name, version, etc.) would require
>             access to some registry?
>
>             Thanks,
>             Charles
>
>                 <mailto:[email-masked]>
>                 Cc: Schmidt, Charles M. <[email-masked]>
>                 <mailto:[email-masked]>; <[email-masked]>
>                 <mailto:[email-masked]>
>                 <[email-masked]> <mailto:[email-masked]>
>                 [1]
>                 https://github.com/athiasjerome/XORCISM/tree/master/MODELS
>
>
>
>                 2016-07-09 0:52 GMT+03:00 Tony Rutkowski
>                 <[email-masked]> <mailto:[email-masked]>:
>
>                     was not able to track down all of those formats,
>                     but it does seem like
>
>                 maybe
>
>                     [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Jul 2016 22:43:13 +0200

On one hand, I completely understand hesitation to add "just the next 
software identifier scheme" instead of using an (appropriate) existing 
one. On the other hand, there is the need to define... something like an 
exhaustive list of information elements to refer to (or even completely 
map) existing representations of software identifiers, which would be 
"the task" of the information model.

This leads to two questions, I think.

If an existing software identifier scheme would be able to represent all 
(or close to all) other ones, would that be a reason to handle that 
representation differently from all other software identifier schemes, 
by including that "most expressive one" into the information model?

If there is no existing solution that can be used in such a way, is it 
really a feasible approach to enumerate an exhaustive list of software 
identifier types and represent all possible attributes of those in the 
sacm information model?

In regard to data models, if it is included in the information model it 
is up to a solution draft to put it into a format, such as JSON, I think.

And to attempt an answer to Charles's question: The usage scenario of 
just transporting an identifier that is supposed to be unique, and using 
that as a hook to retrieve additional information is absolutely viable, 
I think. But it is unlikely that this the only usage scenario and I am 
unsure if that could be considered the default scenario.

Grü0e,

Henk

---

From: Jerome Athias <[email-masked]>
Date: Wed, 13 Jul 2016 17:11:10 +0300

One could find a generalized Identifiers Model in OMG Operational
Threat and Risk Information Sharing and Federation Model, May 2016 at

8.3          Threat-risk-conceptual-model::Foundational
Concepts::Identifiers Page 64

Link https://github.com/ModelDriven/ThreatRisk/blob/master/OMGSubmission/Threat-risk-submission.docx

2016-07-11 23:43 GMT+03:00 Henk Birkholz <[email-masked]>:
> software identifier scheme" instead of using an (appropriate) existing one.
> On the other hand, there is the need to define... something like an
> exhaustive list of information elements to refer to (or even completely map)
> existing representations of software identifiers, which would be "the task"
> of the information model.
>
> If an existing software identifier scheme would be able to represent all (or
> close to all) other ones, would that be a reason to handle that
> representation differently from all other software identifier schemes, by
> including that "most expressive one" into the information model?
>
> identifier types and represent all possible attributes of those in the sacm
> information model?
>
>
> In regard to data models, if it is included in the information model it is
> up to a solution draft to put it into a format, such as JSON, I think.
>
> And to attempt an answer to Charles's question: The usage scenario of just
> transporting an identifier that is supposed to be unique, and using that as
> a hook to retrieve additional information is absolutely viable, I think. But
> it is unlikely that this the only usage scenario and I am unsure if that
> could be considered the default scenario.
>
>
> Grü0e,
>
> Henk
>
>
>
>
>
>>>>>> was not able to track down all of those formats, but it does seem like
>>>>>
>>>>> maybe
>>>>>>

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 13 Jul 2016 19:53:11 +0000

Hi Gunnar,

> The first thing, though is to decide whether or not there is a real need to
> have a separate data model for software inventorying.  My hunch is not:
> since there is a DM/IM that will but under control of SACM, then even if it
> doesn't currently support some data that is available in one of the tag
> systems it can simply be extended to accommodate that.

To clarify: it sounds like this is moving in the direction of "create our own software description structure". Or were you suggested that the IM simply pull in some existing software description structure by reference? 

Charles

> 		To take that a bit further, whether the data to communicate
> is unique software identifiers, a set of descriptive information, or an
> exhaustive list of component details (such as all assemblies and versions),
> that information is still a set of name/attribute pairs with relationships.
> 		So is there something unique about a software inventory
> that requires it to be handled differently from all the other endpoint
> attributes?
> 
> 
> 		--gun
> 
> 
> 
> mind is "what is it that SWID M&A is reporting?" Is it a list of unique
> identifiers for discovered applications, or is it some descriptive information
> about discovered applications. The current draft of SWID M&A supports both
> - it can deliver identifiers and it can deliver descriptive information (currently
> expressed as ISO SWID tags).
> 
> 			Tony - so far, what I am seeing in in your suggestions
> is a lot of unique identifiers, but I have not seen anything that one could use
> to directly encapsulate descriptive information. (I haven't read all the 3GPP
> documents yet, so I might very well have missed something. Of the
> documents I have seen so far, I see lots of use of Application ID, but I appear
> to have missed any spec that provides a standard descriptive structure into
> which that ID can resolve.) OneM2M's App-ID similarly seems to be focused
> on the use of unique identifiers that they manage and not on descriptive
> structures.
> 
> 			So my question to you (and the group): are you
> envisioning a scenario where SWID M&A delivers only unique, non-
> descriptive identifiers as a means of providing software inventory, but any
> resolution of these non-descriptive identifiers into descriptive information
> about an application (name, version, etc.) would require access to some
> registry?
> 
> 			Thanks,
> 			Charles
> 
> 
> 
> 				Cc: Schmidt, Charles M.
> <[email-masked]> <mailto:[email-masked]> ; <[email-masked]>
> <mailto:[email-masked]>
> <[email-masked]> <mailto:[email-masked]> :
> 
> 
> 	Anthony Michael Rutkowski
> 
> 	Yaana Technologies LLC

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Wed, 13 Jul 2016 20:15:26 +0000

Hi Henk,

Just responding to your comment about unique identifiers: I have a lot of concerns regarding this approach if the endpoint in question is not capable of facilitating the resolution of that identifier to a descriptive record. Specifically, if an endpoint is going to report its inventory only via unique identifiers, that endpoint needs to possess evaluation rules that can convert all utilized sources of evidence (e.g., RPM records, SWID tags, inventory tool results, or even just collections of executables on the file system) into the correct identifiers. These rules need to be updated for every patch, update, and newly-installed application of interest since each revision of an application requires a new unique identifier. Every endpoint needs to either manage its rule set independently by collecting these rules from some external source(s), or the rule sets need to be part of the query to which the inventory list is the response. (The latter is basically OVAL.) There also needs to be some party that is managing the mapping between unique identifiers and the evidence that indicates software presence. My experience is that doing this is not simple (and thus, not cheap).

By contrast, if the endpoint is able to provide descriptive information, then each source still needs to be mapped to whatever data model is used for that descriptive record, but once that mapping is defined, descriptions can be created for every revision. The endpoint can then assign its own identifiers to these records. The identifiers can be used to report the inventory and if the recipient doesn't know what an identifier represents, it can use that identifier to get the description from the endpoint itself. These identifiers do not have to be globally unique, and therefore do not need to be globally managed.

Maybe I'm misunderstanding what people are suggesting here, but if people are actually talking about someone creating a list of globally unique identifiers for every version and every variation of even the most commonly used applications, and then having every endpoint have the ability to resolve their inventory status to those identifiers, I don't think that is a sustainable solution.

Charles

> From: Henk Birkholz [mailto:[email-masked]]
> Sent: Monday, July 11, 2016 3:43 PM
> To: [email-masked]; Gunnar Engelbach
> <[email-masked]>; Schmidt, Charles M.
> <[email-masked]>; Jerome Athias <[email-masked]>
> Cc: <[email-masked]> <[email-masked]>
> >>>>> Tony - a while ago you provided a list of other tag formats.

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 13 Jul 2016 13:28:25 -0700

I'm saying a couple of things:

When you get down to it, the information contained in both the SACM IM 
and a software identifier boil down to the same thing:  an identifier, a 
value, and a relationship.  So I'm wondering what the benefit is to 
communicating that type of information in multiple ways?  This is 
especially poignant because consumers of the SACM IM will also need 
access to the installed software information -- it's not an either/or 
proposition.

For example, a security compliance policy would use installed software 
information to not only determine applicability, but also use 
information about optional components, component versions, etc, to 
determine the pass/fail/applicability of individual policy rules.

Detailed installed software information (e.g.: a list of 
assemblies/versions/checksums) would also be used when checking for IoC.

Pulling in some existing software description structure could be the 
fastest way to get there.  In that case, how large and complex a 
structure are we actually talking about?

--gun

---

From: Jerome Athias <[email-masked]>
Date: Thu, 14 Jul 2016 05:26:47 +0300

In short I think we agree that reusing a standardized model is good.
So SWID why not.
Now:
- just a description file or just an ID is not enough to cover some use
cases or requirements that some of us (including Gunnar and myself) have
for covering 'all softwares'
E.g.: a Website is an Application so it's a Software (example of policy:
PCI-DSS).
An in house developed Application is composed of Source Code...and
Components (libraries like DLLs, JARs...) so it's a Software

If we want to cover these use cases also, the SWID or current IM model is
not enough
It would need to be extended
I never found a standardized model for that. So I did my own by merging
various software-related models like OVAL, OWASP, etc. in XORCISM
So I will argue it's feasible and not so big or complex for the discussed
domain

On Wednesday, 13 July 2016, Gunnar Engelbach <
[email-masked]> wrote:

> When you get down to it, the information contained in both the SACM IM and
> a software identifier boil down to the same thing:  an identifier, a value,
> and a relationship.  So I'm wondering what the benefit is to communicating
> that type of information in multiple ways?  This is especially poignant
> because consumers of the SACM IM will also need access to the installed
> software information -- it's not an either/or proposition.
>
> information to not only determine applicability, but also use information
> about optional components, component versions, etc, to determine the
> pass/fail/applicability of individual policy rules.
>
> fastest way to get there.  In that case, how large and complex a structure
> are we actually talking about?
>
>
> --gun
>
>
>
>>> to
>> To clarify: it sounds like this is moving in the direction of "create our
>> own software description structure". Or were you suggested that the IM
>> simply pull in some existing software description structure by reference?
>>
>> Charles
>>
>>> versions),
>>> information
>>> information
>>>                                 stage, that the Data Models are not
>>> 'globally'
>>> optimized, in the sense
>>>                                 that while I can see it working fine for
>>> M2M,
>>> the models seem not
>>>                                 based on (something still not existing)
>>> an
>>> Ontology approach (which
>>>                                 domain only - than the current
>>> ("abstracted")
>>> part of the XORCISM's
>>>                                 model [1] (where you would find
>>> GUIDs...) is
>>> better designed for
>>>                                         documents dealing with
>>> identifiers
>>>                                         - especially for new mobile
>>> network
>>> infrastructure
>>>                                         define identifier schema.  These
>>> are
>>> all
>>>                                         GUID of some kind that is then
>>> used
>>> to
>>>                                         an associated "filter"
>>> expression is
>>> used.
>>>                                         help herd the gazillion software
>>> cats
>>> out there
>>>                                         with a more consistent structure
>>> if it's
>>> a lookup
>>>                                         A significant challenge over the
>>> years
>>> discussing
>>>                                         this topic in many different
>>> venues, is
>>> the lack of
>>>                                         interest.  Good luck.
>>>
>>>                                         --tony
>>>
>>>
>>>                                         several of the major work items
>>> for
>>> Rel. 14 leverage application
>>>                                         identifiers and related tags.
>>> Given
>>> the force and effect of
>>>                                         the global mobile
>>> specifications, they
>>> matter more than
>>>                                         most.
>>>
>>>                                         Tony – a while ago you provided
>>> a list
>>> of other tag formats.
>>>
>>>                                         I think identifier schemes fall
>>> afoul of
>>> Gunnar's guideline #1. Of the
>>>                                         descriptive formats you
>>> identified,
>>> are there any that you would suggest as
>>>                                         meeting the three guidelines
>>> Gunnar
>>> identified?
>>>
>>>
>>>
>>>
>>>