RFC 7617 Quiz

Q1: How must a colon in a proposed Basic user-id be handled?

Multiple Choice · L3

A provisioning form accepts user-id ops:admin and password secret. The client would concatenate them as ops:admin:secret before Base64 encoding.

A. Encode it unchanged because the final colon always separates the user-id from the password B. Reject it: the first colon is the separator, so the recipient would read a different credential pair C. Percent-encode only the colon and rely on the Basic recipient to decode it after Base64

**Explanation:** B is correct. Section 2 constructs user-pass as user-id, one colon, and password. A user-id containing a colon is invalid because the first colon is the delimiter; the example string would be interpreted as user-id ops and password admin:secret. User agents therefore need to reject such input before serialization. A invents a last-colon rule. C invents an escaping layer that RFC 7617 does not define for user-pass. This is an input-validation boundary: silently transforming the value can make the provisioning system and authentication server disagree about the principal.

Q2: What does charset=UTF-8 change in a Basic challenge?

Multiple Choice · L3

A server sends WWW-Authenticate: Basic realm="agents", charset="UTF-8". A client supports this parameter and has a non-ASCII user-id.

A. It encrypts the credential octets with UTF-8 before Base64 encoding B. It changes the credential syntax by adding a charset field inside the token68 value C. It advises the client to convert character data to NFC and encode it as UTF-8 before Base64

**Explanation:** C is correct. Section 2.1 defines charset only on the challenge, with the sole allowed value UTF-8, matched case-insensitively. It signals the server's expectation that character data be converted to Unicode NFC and then UTF-8 octets before Base64. A confuses character encoding with confidentiality; UTF-8 and Base64 are reversible representations. B invents an extensible credential structure, while the RFC notes that Basic credentials use a single token68 and are not extensible in that way. The parameter is advisory, but honoring the shared expectation avoids non-ASCII interoperability failures.

Q3: Where may this Basic credential be reused preemptively?

Multiple Choice · L3

A client successfully authenticated a request to http://example.com/docs/index.html. It later prepares requests to http://example.com/docs/report, http://example.com/other/, and https://example.com/docs/report.

A. Reuse only for the first URI; the other path and the scheme change are outside the derived authentication scope B. Reuse for all three because matching the hostname is sufficient for the same protection space C. Reuse only for the HTTPS URI because a secure transport expands the original HTTP credential scope

**Explanation:** A is correct. Section 2.2 derives the authentication scope by removing the path after the last slash, producing http://example.com/docs/. A client may preemptively reuse the credential for resources with that scope as a prefix. The RFC's examples put both /other/ and the HTTPS scheme variant outside it. B ignores path and scheme. C treats stronger transport as permission to widen credential scope; it is not. The reuse rule is permissive (MAY) within the scope, not a requirement to send credentials on every matching request.

Q4: Should a client forward Basic credentials across this redirect?

Multiple Choice · L3

An agent authenticates over HTTPS to https://api.example/tasks/7. The response redirects to https://collector.example/import. The library would forward the same Authorization value and log its decoded form.

A. Forward it because every redirect inherits the realm and credentials of the original request B. Decode and re-encode it because a new Base64 string creates a fresh credential for the target C. Do not reuse it for the new origin; require its challenge or policy and keep the secret out of logs

**Explanation:** C is correct. Section 2.2 permits preemptive reuse only within the authentication scope. A different authority is not the original origin's protection space, and a redirect does not grant it the credential. The new origin needs an applicable challenge or an explicit application credential policy. A invents inherited membership. B changes only a reversible representation and provides no freshness or confidentiality. Section 4 explains that Basic exposes a reusable password in readily recoverable form; excluding the decoded value from logs is an operational mitigation derived from that threat, not a separate Basic wire-format requirement.

Q5: Does frontend TLS protect a Basic credential on the next hop?

Multiple Choice · L3

A gateway terminates HTTPS, then forwards the unchanged Basic Authorization header to a backend over an observable plaintext connection. Operators say the credential is safe because the client used HTTPS.

A. Yes. Once Basic credentials arrive through any TLS connection, their Base64 form becomes confidential on later hops B. No. TLS protected only the client-gateway hop; the reusable credential is exposed again on the plaintext backend hop C. Yes, provided the backend never decodes Base64 and compares only the encoded token

**Explanation:** B is correct. Section 4 treats Basic as cleartext password transmission over the physical carrier and says it should not protect sensitive information without enhancements such as HTTPS. TLS protection ends where that connection terminates. Forwarding the same credential over plaintext creates a new observable exposure. A turns hop protection into an end-to-end property it does not have. C mistakes not decoding for secrecy; any observer can decode Base64. RFC 7617 does not prescribe the gateway architecture, but every hop carrying the reusable credential needs a protection and trust decision.

Q6: What is missing when a counterfeit gateway prompts for Basic credentials?

Multiple Choice · L3

An agent connects to a hostile gateway that presents a valid-looking Basic challenge. The agent does not authenticate the peer and sends a password also used for other services.

A. Trusted server identity and channel protection; a valid challenge syntax does not authorize the gateway to collect the password B. Nothing. The realm string cryptographically proves that the gateway owns the claimed protection space C. Only a different Base64 alphabet; changing the encoding prevents the gateway from reusing the password

**Explanation:** A is correct. Section 4 explicitly identifies counterfeit-server spoofing: a hostile server or gateway can request a password, store it, and feign an error. Authenticating the TLS peer and restricting which server may request which credential address that trust boundary. B treats the free-form realm label as proof of server identity, which it is not. C changes a public encoding and leaves the credential reusable. Password reuse increases the damage because the hostile gateway may try the same user-id and password against unrelated services.

Q7: Which storage review is supported by RFC 7617?

Multiple Choice · L3

A Basic-auth server stores every password as an unsalted fast digest. The operator argues this is sufficient because the network request carries Base64 rather than the original character string.

A. Accept the design because matching the wire encoding and storage representation prevents offline recovery B. Improve storage so a database leak does not make passwords trivially recoverable; avoid plaintext and unsalted digests C. Store decoded plaintext instead because Basic authentication requires byte-for-byte password retrieval

**Explanation:** B is correct as RFC 7617 security guidance. Section 4 says servers and proxies need password data in some form, but ought to minimize recovery after a leak and ought to avoid plaintext or unsalted digests. The precise modern password-hashing design is outside this RFC. A confuses a reversible wire representation with secure at-rest verification and ignores offline guessing. C overstates the protocol: Basic defines what the client sends, not a requirement to store plaintext. These are recommendations rather than new Basic credential-syntax requirements.

Q8: Which A2A design avoids turning Basic into a delegation token?

Multiple Choice · L4

A gateway validates a client's Basic credential for its own realm. It then plans to copy that same Authorization header through several agents so each backend can act as the user. The backends have different resource policies and trust domains.

A. Forward it unchanged because successful Basic authentication at one gateway authorizes every downstream agent B. Change only the realm label at each hop because the original password proof remains valid for every new protection space C. Keep the password at its intended boundary and use separately protected, scoped evidence for downstream identity and authorization

**Explanation:** C is correct as an application design conclusion. Sections 2 and 2.2 authenticate a user-id/password pair within a Basic protection space and define limited credential reuse. RFC 7617 does not define transitive delegation, downstream audience, resource scope, or authority for unrelated backends. A gateway can authenticate the client, but later hops need their own protected and explicitly scoped trust mechanism. A converts credential verification into universal authorization and exposes a reusable password at every hop. B changes a label without creating a new proof or permission; realms help define protection spaces, not delegation. RFC 7617 does not mandate a particular replacement mechanism, so the application must choose and protect one appropriate to its trust model.

HTTP Basic Authentication

Primary reference

Q1: How must a colon in a proposed Basic user-id be handled?

Q2: What does charset=UTF-8 change in a Basic challenge?

Q3: Where may this Basic credential be reused preemptively?

Q4: Should a client forward Basic credentials across this redirect?

Q5: Does frontend TLS protect a Basic credential on the next hop?

Q6: What is missing when a counterfeit gateway prompts for Basic credentials?

Q7: Which storage review is supported by RFC 7617?

Q8: Which A2A design avoids turning Basic into a delegation token?