diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md
index 254afc9..d8255e1 100644
--- a/book/source/04-certificates.md
+++ b/book/source/04-certificates.md
@@ -167,11 +167,13 @@ A typical User ID identity is a UTF-8-encoded string composed of a name and an e
 
 For further conventions on User IDs, refer to the document [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/), dated 25 August 2023.
 
-One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). 
+**Split User IDs**
 
-```{admonition} Warning
-Heiko, please clarify what the value is of this proposal or remove it. 
-```
+One proposed variant for encoding identities in User ID is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). This style of User IDs is currently uncommon, but there is no technical impediment to using this format right now.
+
+An argument for split User IDs is that a name and an email address are two distinct identities, which are easier to reason about separately. This is particularly relevant when third parties consider certifying that an identity is legitimately connected to a certificate.
+
+For example, some third party may be sure about the email identity of a contact, and happy to issue a certification for an email-based identity (such as `<alice@example.org>`). But they may not have any insight into a name based identity (such as `Alice Adams`), and thus not willing to certify such a name-based identity.
 
 (primary_user_id)=
 ### Implications of the Primary User ID