Subject: [sacm] Endpoint ID Design Team Meeting Notes: 2015-02-20

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 20 Feb 2015 10:45:22 -0600

SACM Endpoint ID Design Team Notes
2015-02-20
==================================

Agenda

	Reminder:
		- WebEx Chat and SACM Jabber Room
		- Recording will be (is) enabled
	Endpoint ID Example Continued
		- Orientation on Information Model draft
		- Continued Provenance Discussion
			- Virtual Interim Considerations
			- W3C investigation considerations
	Next Steps
		- See Below

Attendees
	Clifford Kahn
	Danny Haynes
	David Waltermire
	Jessica Fitzgerald-McKay
	Jim Bieda
	Adam Montville
	Henk Birkholz
	Ron Colvin

Overview
========
Cliff and Dave worked throughout the week on updating the Information Model draft and Cliff posted an update (-01) just this morning (thank you!!).  Most of the changes have been capatured in section 1.1 "Changes in Revision 01".  We are orienting on the changes that have been made to the Information Model.  

(Contentious points are noted herein, otherwise you're encouraged to review the -01 draft as posted.)

There was a brief discussion recognizing that, at the point of collection, an attribute is simply an "endpoint attribute".  However, when that information is used or relied upon, it may be classified based on context to be "posture attribute", "identity attribute", or (perhaps later) some other attribute type.

We are discussing a concern about identities.  We might have an identity of a user rather than the endpoint.  If we call that an endpoint identity, we'd be incorrect because it's an attribute collected from the endpoint but not pertaining to the identity of the endpoint - it pertains to the identity of the user interacting with that endpoint.

Cliff and Henk are discussing network interfaces and whether they're useful for identifying endpoints.  I'm not sure where this discussion ended up, but there's something that needs to be considered here (about 35 minutes in to the discussion).

Do we want to comment on the "normativeness" of the diagram in the Information Model?  We have a lot of verbose text, and a lot of that text is expressed in the diagram.  Provided the diagram is clear and not subject to misinterpretation, then we might consdier this approach.  The diagram appears to be in UML format, but there are "ASCII" adaptations that may need to first be explained (e.g. define some ASCII notations in UML terms).

Jessica is bringing up a metapoint about the diagram.  She's proposing that a diagram may not be the best way to express this stuff.  Some other information models don't use diagrams except in the component model.  Perhaps words or pseudo-code would be better?  This is ONLY something to consider at this point - whether we have a "how to read this diagram" section, or use it in an "informative only" capacity remains to be determined.

We might consider breaking this ASCII diagram apart or using a more robust pictorial method and posting that to the Wiki as an informative reference.  We might also no longer be limited to ASCII art, which could be very useful (Adam will need to look into this).

Do we want to model "account" as part of endpoint identity?  This is useful, perhaps, for targeting scenarios (find all servers where "account x" has logged in, or has an account established).  This may be more "behavioral" than it is "posture" related, and the discussion needs to be had to consider whether this aspect is in scope now or later.

If we try to follow the PROV information model, we're running the risk of being sucked into a swamp.  As Cliff put it, if we do it the PROV way, we're going to carry some frieght.  The notion here is that W3C PROV may not be relied upon at this point.  It's not a matter of using pieces of it, but it's a matter of what we can do.

Future Discussion Points
========================

	* Discuss identification information from bios/firmware (e.g. serial numbers, asset tags, VM id) that can be queried on the device using software
	* Provenance information from W3C PROV
	* Is "account" as an identity attribute in scope?
	* Should *the* ASCII diagram survive as-is, or should it be replaced (with something more robust) or broken apart?  Is the diagram something we want to explicitly state as being normative?

NEXT STEPS (Agenda Items to track)
==================================

	* "Pruny" discussions: Account (above), "Primary" identity attributes (what's sufficient).
		- Desired characteristics of primary attributes
	* Discuss identification information from bios/firmware (e.g. serial numbers, asset tags, VM id) that can be queried on the device using software
	* W3C PROV Homework/Overview