ToppyMicroServices

RFC 8615 Quiz

Discovery locations and origin boundaries

🇺🇸🇯🇵
0 / 0

Primary reference

These questions distinguish the registered path convention from application-defined hostname selection, metadata scope, browser protections, and deployment policy. Section numbers refer to RFC 8615.

Q1: Assuming agent-card is registered, which path is its well-known URI for a supporting scheme?

Multiple Choice
RFC 8615 Section 3 defines a well-known URI whose path begins with /.well-known/ and continues with a registered name, so A has the required top-level position. B places the prefix below another path component. C is only the reserved prefix; the RFC defines no representation there and says clients should not expect that resource to exist.

Q2: Which registration review is correct?

Multiple Choice

An A2A proposal wants clients to use /.well-known/metadata/agents and submits metadata/agents as the registered URI suffix. Its specification defines no syntax for path components after the registered name.

RFC 8615 Section 3 requires the registered name to conform to segment-nz, which excludes /. It also permits a registration to define additional path components, query strings, or fragments. B satisfies both boundaries. A treats multiple segments as one name, C invents composition semantics between registrations, and D still needs a registered suffix before the query.

Q3: What is missing from this registration proposal?

Multiple Choice

A proposal supplies the suffix, change controller, specification document, and provisional status. The specification says only that the resource is “agent metadata”; it defines neither a representation format nor an associated media type. It intends normal HTTP and HTTPS use.

RFC 8615 Section 3 requires the referenced specification to define the retrieved format and associated media type, so C identifies the defect. The RFC neither fixes a hostname or CA nor requires redirects. D is wrong because HTTP and HTTPS are assumed when no schemes are explicitly listed; another scheme would need explicit support.

Q4: Which change is needed before clients can interoperate?

Multiple Choice

An A2A profile registers the suffix a2a. Given the identifier alice@example.com, one client probes example.com, another probes agents.example.com, and both claim RFC 8615 compliance. The profile gives no hostname-selection rule.

RFC 8615 Section 3 explicitly does not define how to determine the hostname; the application must do so. B supplies the missing interoperability and authority rule. A invents a convention, C confuses transport authentication with hostname selection, and D leaves clients with incompatible and potentially unsafe guesses.

Q5: May the client accept the redirected metadata as authoritative?

Multiple Choice

The profile selects tenant.example and fetches https://tenant.example/.well-known/a2a. The server redirects to https://metadata.example.net/a2a/tenant. TLS validation succeeds for both hosts, but the profile says nothing about redirects or cross-origin authority.

RFC 8615 Section 3 leaves discovery and metadata scope to the application, while Section 4.3 warns against assuming administrative relationships across origins. C therefore identifies a missing profile rule. A and B infer delegation that two valid TLS channels do not establish. D overstates the RFC: it does not impose a blanket redirect ban.

Q6: Which client behavior matches the profile and RFC 8615?

Multiple Choice

An A2A profile explicitly defines discovery at https://host.example:9443/.well-known/a2a. A deployment uses that port, while the registered suffix is simply a2a.

RFC 8615 Section 3 says applications typically use the default port, but an alternative port is allowed when the application explicitly specifies it. C follows that rule. A turns a typical choice into a prohibition, B invents port scanning, and D confuses the registered path suffix with the URI authority.

Q7: Which deployment change best preserves the stated trust boundary?

Multiple Choice

platform.example hosts unrelated tenants. Each tenant may publish files under its own path, but a reverse-proxy rule also lets any tenant write /.well-known/a2a. Clients interpret that resource as platform-wide metadata.

RFC 8615 Section 4.1 says well-known locations effectively represent the entire origin and recommends appropriately controlling write access, especially with co-located entities. B aligns ownership with that scope. A mistakes a filesystem/UI convention for protection, C does not prevent malicious content, and D breaks stable discovery without fixing authority.

Q8: Which security review is most accurate?

Multiple Choice

A state-changing well-known endpoint authenticates with a cookie marked HttpOnly; Secure; Path=/.well-known/a2a. An unrelated application on the same origin has an XSS flaw. The design assumes the flags prevent that script from causing authenticated requests to the endpoint.

RFC 8615 Section 4.2 warns that injected same-origin content can make potentially arbitrary requests to a well-known resource. HttpOnly limits script access to the cookie value and Path limits where the browser sends it; neither creates a new origin or by itself authorizes a state change. D separates those mitigations from application-level request validation. A and B overstate cookie flags, while C addresses only name collisions.

Q9: Which review finding best addresses the confidentiality requirement?

Multiple Choice

An origin publishes an Agent Card at /.well-known/agent-card. The card contains a public endpoint and a reusable bootstrap bearer token. An unrelated web application on the same origin can run browser script, while the token must remain confidential.

RFC 8615 Section 4.2 warns that well-known resources remain accessible to browsers and interact with other content on the same origin. The prefix does not create a confidential compartment. C meets the stated public-discovery and token-confidentiality requirements. A only hides a location, B assumes isolation that the RFC does not provide, and D still exposes the credential through a URL and logs.

Q10: May the client apply the discovered policy to both sibling hosts?

Multiple Choice

A user selects billing.example. The client successfully retrieves an HTTPS document from billing.example/.well-known/a2a. It declares its scope to be *.example and names admin.example as an endpoint. The certificate and document signature both validate, but the A2A profile defines no hostname-selection or cross-origin scope rule.

RFC 8615 Section 3 leaves hostname determination and metadata scope to the application. Section 4.3 warns that applying one origin's metadata to another host assumes an administrative relationship that might not exist. HTTPS and a valid document signature authenticate their respective channel and signer; neither supplies the missing A2A authority rule. C identifies the profile work required. D overstates the RFC: cross-host references are not categorically forbidden.

Q11: Which profile change addresses the deployment risk identified by RFC 8615?

Multiple Choice

An enterprise imports 200,000 partner domains. For every domain, its client immediately probes https://domain/.well-known/a2a and retries failures without a bound. Most domains have never opted into A2A, and their web operators report an unexpected request flood.

RFC 8615 Section 4.3 warns that bootstrapping another protocol through a particular hostname can send many unwanted requests to servers that do not implement it, resembling a denial-of-service attack. The RFC does not prescribe one algorithm, but B is the appropriate application-profile mitigation for the stated workload. A mistakes registration for deployment consent, and C and D worsen observability or load without defining applicability.

Q12: Which finding should block deployment?

Multiple Choice

A hosting control panel hides directories whose names begin with a dot. The content-upload account cannot see .well-known in the panel, but an authorization test shows it can write directly to the served /.well-known/a2a path. Administrators assume the hidden directory is protected.

RFC 8615 Section 4.4 warns that administrators may not realize a hidden .well-known directory exists while an attacker with write access can control its contents. C follows the observed permission rather than the UI. A and B confuse hiding with access control, and D ignores that forged discovery metadata can be harmful without executable content.