How is ambiguity strictly avoided when documenting the terms 'secret key' versus 'shared secret' in Time-Based One-Time Password (TOTP) integration guides?

Ambiguity between 'secret key' and 'shared secret' is strictly avoided in Time-Based One-Time Password (TOTP) integration guides through precise terminology, contextual clarity, and the singular purpose of the key within the TOTP protocol. The 'secret key' in TOTP refers specifically to the unique cryptographic key, typically a string of bytes (often 20 bytes for HMAC-SHA1 and frequently Base32 encoded), that is generated by the server during a user's TOTP enrollment. This specific 'secret key' is then securely provisioned to the user's authenticator application. Both the server and the authenticator application use this exact 'secret key' along with a time-based counter to independently compute the TOTP code. For example, an integration guide will instruct a developer to store or use this specific Base32 encoded string as the 'secret key' for OTP generation. A 'shared secret,' conversely, is a broader cryptographic term that describes any piece of data known exclusively by two or more parties, which they can then use for secure communication or authentication. While the 'secret key' used in TOTP *isa type of shared secret because it is known by both the server and the user's authenticator, TOTP documentation avoids ambiguity by consistently using 'secret key' to denote the particular data element that directly serves as the cryptographic input for one-time password generation. The guides are specific: there is only one key value, the 'secret key,' that fulfills this role in the TOTP process for a given user. This focus on the 'secret key' as the direct computational input, rather than a generic 'shared secret,' ensures that developers and users understand precisely which value is required for the TOTP algorithm.