There are quite a few references to creating a claim without a namespace:
If I am reading this correctly there is no way to create a custom id_token to look whatever way you want with custom claims.
“roles”: [ “RoleA”, “RoleB” ]
An id_token is supposed to be lightweight (thus small) as it is included as a Bearer token to authenticate to backend applications via the RP and used to enrich the customer experience. Having to always have a URI means you are expanding the payload by a minimum of 10 bytes for each custom value you want to add. More likely the key will be even longer to reflect the domain the host is using.
Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
But that doesn’t say it MUST include a domain name, only that it is RECOMMENDED.
We were investigating moving from another IDP providers to Auth0 where that IDP allowed us to roll our own id_token with values such as “roles” and other custom claims. To avoid too much re-work we were hoping to keep the same id_token format and just update the authorize and token endpoints to now point to Auth0. But because Auth0 is inflexible with the namespace prefix for the custom claims code changes (albeit quite minor) is required in the applications consuming the IDP.