Is a NEA client a SACM provider or an internal collector?

[llorenzin]

Fundamentally a question of what role a NEA client (for example) plays - is it a SACM provider, or an internal collector, or both, or what?

Continuation of discussion in #29:
Lisa - seems odd to say an internal collector would have a function of discovering the endpoint it's running on
Nancy - wasn't thinking of registration / discovery of target endpoints, but of SACM components
Jess - would an internal collector be able to discover itself?
Henk - internal collector is SACM component, on fringes of SACM domain, on target endpoints that are the assessing component at the same time
Nancy - what does internal collector mean?
Henk - SACM component is part of SACM domain, runs on endpoints that are typically not target endpoints
target endpoints are endpoints of interest, to be assessed
Outside SACM domain is rest of the world visible to SACM domain
Fringe use case - line blurs because endpoint is target endpoint and also SACM component - "internal" collector resides on it
Lisa - I didn't think having an internal collector made a target endpoint a SACM component
Think the SACM component is the provider that rolls up the collection results
Nancy - that was my thought as well
Henk - target endpoint becomes a SACM component because it has building blocks running on it - SACM functions, registrative broker and publishers
Lisa - don't think every target endpoint is a SACM component - only if it's also a provider
Henk - only if it has an internal collector on it
Jess - distinction between an internal collector and a provider - why?
Lisa - internal collector doesn't necessarily publish into SACM ecosystem
if it doesn't publish, it's not a SACM component
Jess - NEA world, collector provides information to a server, which is part of the control plane
Lisa - NEA server is the provider, NEA client is just software on endpoint
Henk - semantically, if a piece of software on an endpoint is speaking SACM - can discover guidance or register to a broker - this can be the case, should be highlighted - it's a SACM component
if just produces information and transports it to the first SACM component, then this is remote collection
typical collection that over the network is assessing the endpoint
maybe have a trusted, registered, attested component on the target endpoint - could trust it
Lisa - that's not what an external collector is either
In the NEA example the NEA client is just software on the endpoint
it's not a SACM component - doesn't publish into the provider/consumer ecosystem, doesn't use a SACM transport
NEA server is the provider, so it aggregates the information from the internal collectors on target endpoints and uses the SACM transport to provide that information
Jess - wasn't aware this group had defined a transport
Nancy - XMPP-Grid is a proposed transport
Jess - what about IF-T TLS?
Henk - transport here is overloaded
Lisa - we decided not to specify the transport between the target endpoint and the SACM component
SACM transport is transport between SACM components
other transport between endpoint and SACM component
Jess - NEA client publishing data about itself, is that a SACM component?
Lisa - if it's publishing directly, yes
Nancy - think you're mixing implementation details
if you made the NEA client become a SACM provider, adhered to the data model, then yes
Lisa - endpoint can be a SACM component but doesn't have to be
Henk - we don't define how you get information from the target endpoint
Just says the SACM component uses any means to get information from the target endpoint
Think this is restricting the scope of the SACM domain, important choice, should be highlighted to the email list
Understand the argument - don't see why you can't allow a SACM component to reside on a target endpoint
Lisa - not saying that - like difference between TNC client and IMC - IMC is like internal collector, TNC client is like SACM component
Josh - have a simple drawing?
Lisa - would be good to have a drawing showing relationships between functions and components
Josh - basic entity / relationship map

[llorenzin]

NCW - I see a NEA client as a target endpoint - that client is what we're trying to assess posture for
Could think of a NEA client as potentially being a SACM consumer - a provider could be specifying the guidance to that NEA client
LL - the target endpoint is the subject of assessment - the NEA client is the software doing the collection - NEA client is in my opinion always an internal collector
I agree it could be a SACM consumer as you say
In some cases it might be a SACM provider - if it's publishing the assertions directly to the SACM ecosystem
But in some cases it might not be a SACM provider - if a compliance server is gathering collection results from it and the compliance server is publishing the assertions, then the NEA client isn't a SACM provider -it's the compliance server that's the SACM provider
DH - possible that it could be a multi-step process to get the collection result from the NEA client to the compliance server
LL - it depends on whether it's using a SACM standardized interface there
we said we weren't going to standardize the interface between NEA client and compliance server
NCW - depends on the implementation of the software
application could decide that it's playing role of NEA client as well as of SACM provider and consumer
LL - if the software performing the collection - (example: NEA client) is using a SACM standardized interface to publish the data to the SACM ecosystem, then it's a SACM provider
if it's not - if it's using a non-SACM interface to provide the collection result to something else (example: NEA server), which then publishes the information using a SACM interface, then the endpoint software is not a SACM provider
IM - do we have a word for that?
LL - it's a SACM provider - haven't gotten more specific than that - could be McAfee EPO / centralized endpoint security system, could be a NEA server
IM - could be a WMI
LL - collection result aggregator? Collection result recipient?
Anything useful in TNC Endpoint Compliance Profile? We talk about a compliance server, and that's one instance of what this would be
JFM - worry that we're over-simplifying in an attempt to make a simple architecture
internal collector that speaks a protocol standardized by SACM is part of SACM ecosystem
LL - collector doesn't have to, it's the consumer/provider that has to

Will need more discussion