Identifying Artifact ID construction goals

[alilleybrinker]

The following is adapted from discussion at the April 15th, 2024 Working Group meeting.

---

We currently have multiple open issues relating to the construction of the Artifact ID in the OmniBOR specification.

• Replace GitOID construction with plain SHA-256
  • Consider replacing GitOID Construction with plain SHA-256 · omnibor · Discussion #76 (github.com)
• Reduce required hashes to only SHA-256
  • Alternative: officially support SHA-1, SHA-1DC, and SHA-256
    • Amend Artifact Identifiers to use SHA-1DC, SHA-1, and SHA-256, to match Git. · Issue #70 · omnibor/spec (github.com)
• Remove support for custom hashes for Artifact ID construction
  • Permitting arbitrary custom hashes as the basis for Artifact Identifiers should be removed. · omnibor · Discussion #69 (github.com)

@dpp suggested we may be better off, before getting into the meat of these discussions, first identifying our goals for the construction of the Artifact Identifier. Some of these have already been enumerated, or at least considered, in #76.

@ashleygwilliams also suggested we could write what amounts to a "retrospective Request for Comments (RFC)" to describe these goals as the outcome of this initial discussion.

The current plan is to make this discussion a primary topic for the April 22nd, 2024 meeting of the Working Group.

[edwarnicke]

I think historically we've wanted our artifact (and by extension manifest) identifiers to have the following characteristics:

• Canonical - Independent parties, presented with equivalent artifacts, derive the same artifact identity.
• Unique - Non-equivalent artifacts have distinct identities.
• Immutable - An identified artifact can not be modified without also changing its identity.

Clearly, at any given moment in time, any well formed hash meets these characteristics.

I'd suggest we consider these 'tier one' requirements.

At tier 2, we have questions like:

• How many useful artifacts are already indexed by this hash?
• How expensive is this hash to compute?
• How expensive is this hash to store?
• How durable is this hash likely to be? (ie, how long before it's broken, note: this is a guess generally)

Its also worth considering "Required of what when?". We have a few distinct cases we've already identified:

• Required of build tools at build time
• Required of metadata indexing tools at indexing time
• Required of ADG/metadata stores at query time

[alilleybrinker]

Aeva has noted that the initial version of the specification reflects goals for the identifier which we should refer to / capture here as part of this discussion.