diff --git a/book/source/09-verification.md b/book/source/09-verification.md
index 8691c74..364b351 100644
--- a/book/source/09-verification.md
+++ b/book/source/09-verification.md
@@ -20,10 +20,14 @@ A signature might be correct, but still disqualify as a valid signature.
 Put mathematically, the set of valid signatures is a subset of the set of correct signatures.
 
 The validity of a correct signature is additionally constrained by a number of conditions:
-Signatures need to be well-formed, meaning they must contain required signature subpackets in the proper subpacket area and must not contain unknown critical subpackets or notations.
-Most signatures have a limited validity period, constrained by the signature creation- and expiration time.
-Furthermore, some signatures need to be *qualified* by another valid signature in order to be considered valid.
-Lastly, signatures can be invalidated by revocations.
+* well-formedness  
+  Signatures need to be well-formed, meaning they must contain required signature subpackets in the proper subpacket area and must not contain unknown critical subpackets or notations.
+* temporal validity  
+  Most signatures have a limited validity period, constrained by the signature creation- and expiration time.
+* qualification  
+  Furthermore, some signatures need to be *qualified* by another valid signature in order to be considered valid.
+* revocation  
+  Lastly, signatures can be invalidated by revocations.
 
 ### Temporal validity
 
@@ -44,10 +48,15 @@ Typically, self-qualifying signatures are self-signatures, meaning signatures is
 Examples for self-qualifying signatures are direct-key self-signatures (0x1F), User-ID self-certifications (0x10-0x13), key-revocation self-signatures (0x20), certification revocation self-signatures (0x30) or signatures used to bind or revoke subkeys (0x18, 0x19, 0x28).
 
 Examples for signatures which are not self-qualifying are data signatures (0x00, 0x01) and signatures issued over third-party certificates, such as third-party direct-key signatures (0x1F) or key-revocations (0x20), third-party certification or revocation signatures (0x10-0x13, 0x30).
-To verify such signatures, it is not sufficient to only look at the signature itself.
 
+### Signature qualification
+
+To verify non-self-qualifying signatures, it is not sufficient to only look at the signature itself.
 The reason is, that the issuer (sub-) key needs to be qualified to create such a signature.
 This qualification typically comes via another self-signature on the key itself.
+
+Instead, a chain of valid signatures from the signature itself to the primary key of the issuer certificate needs to be established.
+
 For example, a data signature over an email body may be issued by a subkey only if that subkey is validly bound to the users certificate via a subkey binding signature, and that binding signature needs to contain a key flags subpacket marking the subkey as **S**igning capable.
 Similarly, certification signatures over third-party certificates require the issuer key to carry a self-signature qualifying it to **C**ertify other keys.
 
@@ -60,6 +69,9 @@ On the other hand, in order to verify a data signature over a text document, an
 ```{include} mermaid/09-sigtree.md
 ```
 
+### Attribute Shadowing
+TODO
+
 ### Revocations
 
 A signature might be *disqualified* by the presence of a revocation signature.
@@ -70,7 +82,21 @@ TODO: Give guidance, which revocations need to be considered for different types
 
 ## Which signatures take precedence?
 
-An OpenPGP certificate can have multiple signatures with conflicting information in them.
+An OpenPGP certificate or component can have multiple signatures with conflicting information attached to it.
+
+When verifying a non-self-qualifying signature, an implementation needs to identify self-qualifying signatures on the certificate to qualify that signature.
+There might be more than one candidate for such a signature.
+
+For example, there might be multiple subkey binding signatures for the same subkey.
+In general, for each category of signatures, only that with the latest signature creation time is considered and takes precendence.
+
+Alternatively, there might be competing qualifying signatures of different types, e.g. a direct-key signature and a self-certification signature on a primary User-ID.
+In this case, depending on how a key is "addressed", different attributes from both candidates "shadow" another.
+
+```
+TODO: Replace hash algorithm preferences with AEAD preferences for a more realistic example.
+```
+
 For example, the latest direct-key signature could list "SHA512, SHA384" as hash algorithm preferences, while the latest self-certification of User-ID "Bob" could list "SHA256" only.
 For yet another User-ID "Bobby", the self-signature could list no hash algorithm preferences at all.
 If the user wants to compose a signed message using the associated OpenPGP key, they need to figure out, which preferences to use.