Package Identity

An MSIX package identity is composed of a five-part tuple that uniquely identifies a package. It consists of the following attributes:

• Name
• Version
• Architecture
• Resource Id
• Publisher

Together, these fields form the canonical identity of a package. Programmatically, this identity can be represented using APIs such as Windows.ApplicationModel.PackageId or the PACKAGE_ID structure.

Why Package Full Name?

Working directly with the individual identity fields is often inconvenient. To simplify common scenarios, Windows defines an opaque string representation that encapsulates the entire five-part identity: the Package Full Name.

This canonical form provides a convenient way to serialize and pass package identity across system boundaries – such as APIs, file systems, access control lists (ACLs), policy configurations, and other components – without requiring callers to parse or manipulate individual fields.

Why PublisherId?

The Publisher field is an X.509 subject distinguished name. While precise, it can be quite large (up to 8 KB) and may contain characters (such as spaces, backslashes, and ampersands) that are cumbersome in paths, identifiers, or protocol payloads.

To address this, Windows derives a compact shorthand known as the PublisherId.

A PublisherId:

• Is computed as a hash of the Publisher string
• Is always 13 characters in length
• Is encoded using the Crockford variant of Base32

The result is a short, fixed-width, ASCII alphanumeric identifier suitable for use in contexts where the full X.509 subject name would be impractical.

Why Package Family Name?

In some scenarios, the full package identity is overly specific.

For example, if application configuration were tracked per-package, updating a package from version 1.0.0.0 to 1.0.0.1 would produce a new identity – and therefore a completely separate configuration state.

In such cases, a version-independent¹ identifier is preferable.

The Package Family Name provides this abstraction by identifying a package in a manner that is independent of:

• Version
• Architecture
• ResourceId

Common uses include tracking security assignments and persistent configuration at the Package Family level rather than per individual package instance.

¹ More precisely: independent of version, architecture, and resource id.