User object definition fix

[floydtree]

Related Issue: None

Description of changes: non-breaking

1. The user object's definition contained a erroneous property for the name attribute, cleaning that up.
   • per @mikeradka this might be intentional to allow functionality of observables, adding it back out of caution. We should confirm this and add a section in the contribution guide to explain this behavior.
2. Adding explicit requirement property where missing.

[Aniak5]

LGTM

[mikeradka]

I am not sure this is erroneous. There is a chance that this could be breaking for those using observables. I think username_t is there because it is an observable type, which is used for identifying & generating observables.

I believe that in this link: https://schema.ocsf.io/1.0.0/data_types?extensions=, all of the data types that contain an O at the end are what causes an object to be identified as an observable (for example, file_hash_t, file_name_t) - compare those to the 'observables' type_id enum: https://schema.ocsf.io/1.0.0/objects/observable?extensions=

A practical example: I believe the OCSF translator looks at the datatype, and when the datatype of a given object matches an observable type, it identifies that object as an observable.

[floydtree]

Interesting, if that's the case it should be documented in the contribution guide, do you mind adding a section for how to define observables or something similar? @mikeradka
Out of caution, I am adding that property back to the object.

[mikeradka]

Interesting, if that's the case it should be documented in the contribution guide, do you mind adding a section for how to define observables or something similar? @mikeradka Out of caution, I am adding that property back to the object.

Great minds think alike, my friend. I was just digging into the docs to see if it is specified anywhere. Thanks for adding it back - we definitely don't want to break use of observables.

I am spinning up some local tests on my side to cover observable datatypes/generation more thoroughly. Once I better wrap my head around it i'll be sure to add to our docs! Tracking in the docs repo here: ocsf/ocsf-docs#32