Arbitrary secrets protocol feedback

[indomitableSwan]

Feedback summary, with some responses/plan for incorporation. Typos and writing improvements not included, and if feedback no longer relevant (i.e., error already fixed prior to processing feedback), then not duplicated here.

System Architecture suggestions:

1. [Done] Explicitly note that we are using TLS for server authenticity. ---> Technically, this is only true for registration, and in the redesign with MACs instead of an additional inner encryption layer, we also rely on TLS for confidentiality. We can clarify this.
2. [Done] Consider refactoring session descriptions to make overlap between "registration" and "request" sessions clearer.
3. Is the freshness of user_id in OPAQUE registration for security or usability?

Operations on Arbitrary Secrets:

1. [Done] System isn't currently very usable across devices because users don't have a way of knowing their identifiers on a new device. ---> This problem is already documented with a potential solution here.
2. [Fixed already] Might want to do server lookups based on key id as well as user id. ----> Agreed. I believe this has already been fixed/documented in issues, but this should be double checked.
3. [Done] Inconsistent level of generality in specification of cryptography dependencies. ----> Agreed. This shouldn't mandate the HMAC-KDF here; the actual selection should be recorded a level up.
4. [Done] Add additional description on seeding of CSPRNG.
5. For secrets, consider binding the secret material and context so that you cannot use the key without checking the context first, e.g., compute the secret as a Hash that incorporates a seed and the context.
6. [Done] Clarify description of retrieve storage functionality, i.e., which inputs are client's vs server's? ----> Agreed. This also isn't the only place where this isn't fully specified.

[indomitableSwan]

Closing out this epic as we have received no further feedback/clarification of previous feedback.