Skip to content

HardwareManifest Proto

HardwareManifest.proto defines the protobuf ManifestV2 format used project-wide, including by the ComponentClassRegistry libraries. paccor's HardwareManifestJsonHelper reads JSON that mirrors that shape closely enough that the same manifest can move from collection tools to certificate generation without an intermediate translation layer.

Source: dotnet/HardwareManifestPlugin/HardwareManifestPlugin/Resources/HardwareManifest.proto

ManifestV2

At the top level, the protobuf carries platform identifiers, component entries, optional platform properties, and optional URI indirections for hosted component or property lists.

message ManifestV2 {
  SanPlatformFields PLATFORM = 1;
  repeated ComponentIdentifier COMPONENTS = 2;
  repeated Property PROPERTIES = 3;
  UriReference COMPONENTSURI = 4;
  UriReference PROPERTIESURI = 5;
}
Proto field JSON field paccor schema
PLATFORM PLATFORM (or platform) SAN Platform Fields
COMPONENTS COMPONENTS (or components) Component Fields
PROPERTIES PROPERTIES (or properties) Component Property Fields
COMPONENTSURI COMPONENTSURI (or componentsUri) URI Reference Fields
PROPERTIESURI PROPERTIESURI (or propertiesUri) URI Reference Fields

ComponentIdentifier (proto)

ComponentIdentifier carries the hardware facts that eventually become PlatformConfiguration* content inside the certificate.

message ComponentIdentifier {
  ComponentClass COMPONENTCLASS = 1;
  string MANUFACTURER = 2;
  string MODEL = 3;
  string SERIAL = 4;
  string REVISION = 5;
  string MANUFACTURERID = 6;
  string FIELDREPLACEABLE = 7;
  repeated Address ADDRESSES = 8;
  string STATUS = 9;
  CertificateIdentifier PLATFORMCERT = 10;
  UriReference COMPONENTPLATFORMCERTURI = 11;
  CertificateIdentifier CERTIFICATEIDENTIFIER = 12;
  repeated PlatformCertificateProto.Trait TRAITS = 13;
}

paccor accepts the protobuf-style all-caps property names as well as the canonical Java-style aliases documented in the generated field pages. The runtime deserializers are intentionally tolerant on input so that manifests produced by older tools, mixed-case serializers, or hand-authored JSON can still be normalized into the canonical internal model.

See Component Fields for the exact field table and the backing ASN.1 type.

Case-insensitive input

Several JSON helpers are configured to accept case-insensitive property names. In practice, that means COMPONENTCLASS, componentClass, and similar variations can still resolve successfully as long as the underlying field is known. The generated reference pages still present the canonical form first, because that is the clearest representation for new documents and long-term tooling.

See also