A draft sequence for the city's protected Intersight inventory pull shows the resource GET before any token acquisition hop. What is wrong with that diagram from a Domain 1 sequence perspective?
Select an answer to reveal the explanation.
Short Explanation
You cannot knock on a locked door before you pick up the key. On the diagram, the token hop comes first; then the protected resource call. Wrong order is the defect—not a full OAuth lecture.
Full Explanation
Protected resource access on a sequence diagram must respect authentication order. If the city’s Intersight inventory GET requires a token, the token acquisition hop (client credentials, refresh, or equivalent) must appear before the protected resource call. Drawing the GET first is a Domain 1 sequencing defect: the diagram claims an order that cannot succeed against a locked API.
Listing every OAuth2 grant type from the RFC as separate lifelines over-specifies the diagram; the defect is call order, not missing grant encyclopedia. Claiming Intersight requires NETCONF instead of REST on sequence diagrams invents a transport mandate unrelated to the ordering bug. Saying protected resources never appear and only UI clicks belong on diagrams contradicts the purpose of showing the inventory pull.
Exam caveat: token reuse across calls can be shown once then referenced, but the first protected call in the flow still cannot precede first token acquisition. Operational check: validate the draft against a real Intersight session—capture that the auth/token request completes successfully before the inventory GET in both the diagram and a traced client run. If a cached token may already exist, show a brief check or reuse note—but still never draw the protected Intersight inventory GET as the first message of an unauthenticated session. Civic integrations that reverse this order fail in staging with 401s that look like “API flakiness” when the real defect is diagram-faithful wrong sequencing in the client.