define vendor key for added metadata

[lrvick]

So I feel we need an added statement to add a compromise for #10

I know many orgs will have extra metadata they want to sign as part of automation or general evidence etc. Maybe an org wants to include their CI job ID, or has their own review format. Maybe they already use something like Google's git-appraise and want to be able to include hashes of their detailed review blobs from the refs/notes/devtools/reviews ref in their git/refs/signatures. Maybe they want to include ticket numbers from their internal issue system etc.

I don't think we should stop people from including data they feel is valuable to show context around a change, but we should regulate that it goes somewhere that the spec won't ever interpret.

I suggest we include a vendor key to allow for use cases we can't think of yet.

E.g. make new pre-spec git-signatures features use the: ""vendor: { git-signatures:{} }" namespace

[Ekleog]

Hmm… any reason not to have these vendor-specific data go into the review message?

[oxij]

This feels like "User-Agent" field. I think #10 (comment) is a better approach.

[Ekleog]

This is blocked on #4 / #10