A few more small changes to the dynamic clients proposal

proposals/1125_dynamic-supervisor-oidc-clients/README.md

@@ -174,7 +174,7 @@ A brief description of each field:
 - `phase`: This enum (`Pending`,`Ready`,`Error`) summarizes the overall status of the client (defaults to `Pending`).
 - `totalClientSecrets`: The number of client secrets that are currently associated with this client.
 - `conditions`: The result of validations performed by a controller on these CRs will be written by the controller on
-  the status. And example condition is showed above, and other conditions will also be added by the controller.
+  the status. An example condition is shown above, and other conditions will also be added by the controller.
 
 All `.spec` list fields (i.e. all of them) will be validated to confirm that they do not contain any duplicates and are
 non-empty.
@@ -319,7 +319,7 @@ pinniped-supervisor     client.oauth.pinniped.dev-j77kz     12..xz     2
 ```
 
 All client secret hashes for an OAuth client will be stored in `pinniped-storage-oidc-client-secret-<metadata.uid>` where
-`metadata.uid` is a hashed version of the UID generated by the Kuberentes API server for the `OIDCClient` custom resource instance that
+`metadata.uid` is a base32 encoded version of the UID generated by the Kuberentes API server for the `OIDCClient` custom resource instance that
 represents the given OAuth client.  This secret will have an owner reference back to the `OIDCClient` to guarantee that
 it is automatically garbage collected if the `OIDCClient` is deleted.  As the client secret lookup is UID based, it is
 resilient against any vulnerabilities that arise from the client ID being re-used over time.  Using the UID also
@@ -327,7 +327,7 @@ prevents any issues that could arise from giving the user control over the secre
 issues, validation issues, etc).  Each client will have a 1:1 mapping with a Kubernetes secret - there would always be
 at most one Kubernetes secret per client.  Since the secret name is deterministic based on the client UID, no reference
 field is required on the client.  Kubernetes secrets have a size limit of ~1 MB which is enough to hold many thousands
-of hashes.  This API will enforce a hard limit of 100 secrets per client (having this many client secrets is likely a
+of hashes.  This API will enforce a hard limit of 5 secrets per client (having this many client secrets is likely a
 configuration mistake).
 
 The bulk of the aggregated API server implementation would involve copy-pasting the concierge aggregated API server
@@ -399,10 +399,10 @@ To address all of these issues we will:
 - Implicit behavioral changes to APIs are avoided as they can be difficult to understand and reason about.
 
 The validation associated with dynamic clients will be used to enforce that clients have `metadata.name` set to a value
-that starts with `client.oauth.pinniped.dev-`.  Thus while it will be possible to create a dynamic client CR with a name
-such as `pinniped-cli`, it will not be valid and will not be usable.  For the time being, the hardcoded `pinniped-cli`
-client will not be represented in the CRD API (for a few reasons, i.e. it is a public client while all dynamic clients
-will be confidential clients).
+that starts with `client.oauth.pinniped.dev-`.  Users will be prevented from creating CRs without this prefix, thus
+it will not be possible to create a dynamic client CR with a name such as `pinniped-cli`.
+For the time being, the hardcoded `pinniped-cli` client will not be represented in the CRD API (for a few reasons, i.e.
+it is a public client while all dynamic clients will be confidential clients).
 
 This design subdivides all possible token exchange requested audience strings into several categories. A requested
 audience string may be either the word `pinniped-cli` (rejected), may contain the substring `.oauth.pinniped.dev`