The Device lifecycle shown in Figure 1 implies information needs to flow between businesses when there is a transfer of physical control over a Device (see 4.2.3). How this information is transmitted is out of scope but it could be email, a block chain ledger, cloud based webservice, a file on a USB stick or some other mechanism. This specification defines the format of a document that contains information that needs to be provided with a Device. A Ticket is the term used for a document that describes one or more Devices and has a Digital Signature that can be used to verify that the contents of the document have not been altered and that they confirm the origin of the Device.

Tickets are long lived documents which means the signing Certificate should be issued by a widely trusted root Certificate Authority that is likely to be in business even if the Manufacturer or CompositeBuilder has gone out of business. Tickets allow additional Signatures to be added at any time by an entity in the chain of physical control. The current owner of a Device validates the Ticket by choosing a Signature created by an authority it trusts.

For example, a CompositeBuilder re-signs the Tickets for the Devices to associate the CompositeInstanceUri with the Device Ticket (see 8.1). Customers of the CompositeBuilder will not need a relationship with the Manufacturer of the Device to validate the Ticket.

DeviceIdentity Certificates are typically signed with a chain ending in a root CA owned by the Manufacturer or CompositeBuilder. Tickets are typically signed with a Certificate issued to the Manufacturer by a well-known root CA. Issuer Certificates for Certificates used to sign Tickets shall have the cRLDistributionPoints or authorityInfoAccess extensions defined (see RFC 5280).