update with decriptor

On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

Author: morrison-sap

content/docs/concepts/signing-and-verification-concept.md

@@ -15,11 +15,11 @@ Software supply chains involve multiple stages: development, build, packaging, d
 - **Replaced** — components could be swapped for compromised versions
 - **Misattributed** — components could falsely claim to come from a trusted source
 
-Signing addresses these risks by creating a cryptographic proof that:
+Signing addresses these risks by creating a cryptographic proof of:
 
 1. **Integrity**: The component has not changed since it was signed
 2. **Authenticity**: The signature was created by someone with access to the private key
-3. **Non-repudiation**: The signer cannot deny having signed the component
+3. **Provenance**: The signer cannot deny having signed the component
 
 ## How OCM Signing Works
 
@@ -65,9 +65,12 @@ Each artifact's digest is calculated using a type-specific normalization algorit
 
 | Artifact Type | Algorithm | Description |
 |---------------|-----------|-------------|
-| Generic blob | `genericBlobDigest/v1` | Direct hash of blob content |
+| OCI artifact | `ociArtifactDigest/v1` | Digest of the OCI manifest (used for container images, Helm charts, and other OCI-native content) |
+| Generic blob | `genericBlobDigest/v1` | Direct hash of blob content (used for executables, blueprints, and other non-OCI content) |
 
-This allows OCM to use the most appropriate digest mechanism for each artifact type. For example, OCI artifacts use their manifest digest rather than re-hashing the blob, ensuring consistency with OCI registry behavior.
+This allows OCM to use the most appropriate digest mechanism for each artifact type.
+OCI artifacts use their manifest digest rather than re-hashing the blob,
+improving performance and ensuring consistency with OCI registry behavior. Generic blobs are hashed directly.
 
 #### Recursive Component References
 
@@ -95,11 +98,56 @@ OCM signs a **digest** of the component descriptor, which includes:
 - Source references
 - Component references
 
-The signature does **not** cover the raw resource content directly—instead, it covers the **digests** of those resources as recorded in the component descriptor. This means:
+The signature does **not** cover the raw resource content directly — instead, it covers the **digests** of those resources as recorded in the component descriptor. Crucially, the `access` field (which describes *where* a resource is stored) is **excluded** from the signed digest by the normalization process. This is a key design principle:
 
-- Any change to resource content changes its digest, invalidating the signature
-- Signature verification is fast (no need to re-hash large binaries)
-- Resources can be stored separately while still being integrity-protected
+- **Location-independent integrity** — a component version can be transferred to a different registry (changing all `access` references) without invalidating its signature. The digest remains stable because it depends only on *what* the artifacts contain, not *where* they are stored.
+- Any change to resource content changes its digest, invalidating the signature.
+- Signature verification is fast (no need to re-hash large binaries).
+
+This separation of content identity from storage location is what enables secure delivery across environments: a producer signs a component version once, and consumers can verify it after any number of transfers — even into air-gapped environments with completely different registries.
+
+The following example shows a signed component descriptor. Notice that each resource has both an `access` field (storage location) and a `digest` field (content hash). Only the `digest` is included in the signature — the `access` can change freely during transfers:
+
+```yaml
+component:
+  name: github.com/acme.org/helloworld
+  version: 1.0.0
+  provider: acme.org
+  resources:
+    - name: mylocalfile
+      type: blob
+      version: 1.0.0
+      relation: local
+      access:                          # NOT included in signature
+        type: localBlob
+        localReference: sha256:70a257...
+        mediaType: text/plain; charset=utf-8
+      digest:                          # Included in signature
+        hashAlgorithm: SHA-256
+        normalisationAlgorithm: genericBlobDigest/v1
+        value: 70a2577d7b649574cbbba99a2f2ebdf27904a4abf80c9729923ee67ea8d2d9d8
+    - name: image
+      type: ociImage
+      version: 1.0.0
+      relation: external
+      access:                          # NOT included in signature
+        type: ociArtifact
+        imageReference: ghcr.io/stefanprodan/podinfo:6.9.1@sha256:262578cd...
+      digest:                          # Included in signature
+        hashAlgorithm: SHA-256
+        normalisationAlgorithm: genericBlobDigest/v1
+        value: 262578cde928d5c9eba3bce079976444f624c13ed0afb741d90d5423877496cb
+signatures:
+  - name: default
+    digest:
+      hashAlgorithm: SHA-256
+      normalisationAlgorithm: jsonNormalisation/v4alpha1
+      value: 91dd197868907487e62872695db1fa7b397fde300bcbae23e24abc188fb147ad
+    signature:
+      algorithm: RSASSA-PSS
+      mediaType: application/vnd.ocm.signature.rsa.pss
+      value: 7feb449229c6ffe368144995432befd1505d2d29...
+```
 
 ### Signature Storage
 

content/docs/how-to/configure-signing-credentials.md

@@ -24,8 +24,8 @@ Set up credential configuration so OCM can find your signing keys when signing o
 ## Steps
 
 {{< steps >}}
-
 {{< step >}}
+
 ## Create your .ocmconfig file (optional)
 
 Create `$HOME/.ocmconfig` if it doesn't exist: