ainer image URI (e.g. %[1]soci://<image-uri>%[1]s)
			  * (note that if you provide an OCI URL, you must already be authenticated with
			its container registry)

			By default, this command will attempt to fetch relevant attestations via the
			GitHub API using the values provided to %[1]s--owner%[1]s or  %[1]s--repo%[1]s.

			To instead fetch attestations from your artifact's OCI registry, use the
			%[1]s--bundle-from-oci%[1]s flag.

			For offline verification using attestations stored on disk (c.f. the download command)
			provide a path to the %[1]s--bundle%[1]s flag.

			## Additional Policy Enforcement

			Given the %[1]s--format=json%[1]s flag, upon successful verification this
			command will output a JSON array containing one entry per verified attestation.

			This output can then be used for additional policy enforcement, i.e. by being
			piped into a policy engine.

			Each object in the array contains two properties:
			* an %[1]sattestation%[1]s object, which contains the bundle that was verified
			* a %[1]sverificationResult%[1]s object, which is a parsed representation of the
			  contents of the bundle that was verified.

			Within the %[1]sverificationResult%[1]s object you will find:
			* %[1]ssignature.certificate%[1]s, which is a parsed representation of the X.509
			  certificate embedded in the attestation,
			* %[1]sverifiedTimestamps%[1]s, an array of objects denoting when the attestation
			  was witnessed by a transparency log or a timestamp authority
			* %[1]sstatement%[1]s, which contains the %[1]ssubject%[1]s array referencing artifacts,
			  the %[1]spredicateType%[1]s field, and the %[1]spredicate%[1]s object which contains
			  additional, often user-controllable, metadata

			IMPORTANT: please note that only the %[1]ssignature.certificate%[1]s and the
			%[1]sverifiedTimestamps%[1]s properties contain values that cannot be
			manipulated by the workflow that originated the attestation.

			When dealing with attestations created within GitHub Actions, the contents of
			%[1]ssignature.certificate%[1]s are populated directly from the OpenID Connect
			token that GitHub has generated. The contents of the %[1]sverifiedTimestamps%[1]s
			array are populated from the signed timestamps originating from either a
			transparency log or a timestamp authority – and likewise cannot be forged by users.

			When designing policy enforcement using this output, special care must be taken
			when examining the contents of the %[1]sstatement.predicate%[1]s property:
			should an attacker gain access to your workflow's execution context, they
			could then falsify the contents of the %[1]sstatement.predicate%[1]s.

			To mitigate this attack vector, consider using a "trusted builder": when generating
			an artifact, have the build and attestation signing occur within a reusable workflow
			whose execution cannot be influenced by input provided through the caller workflow.

			See above re: %[1]s--signer-workflow%[1]s.