fix: set application_id when provisioning resources

[Larry-Osakwe]

Fixes the provisioning bug under the retracted finding, and it closes ECO-297 as a side effect.

The bug

bin/provision created resources with credential_provider_id and linked the application as a dependency, never as the resource owner. svc-sts gates re-exchange on that owner: it compares resource.application_id against the authenticated client before accepting a zone-issued access token as a subject_token. With the field unset the comparison runs against undefined and every exchange fails with invalid_grant, while impersonation keeps working — so it presents as a token problem rather than a provisioning one. Dependencies don't stand in for it: they let the application request tokens, not own the resource.

Now set at creation time, with an idempotent PATCH to backfill zones provisioned before this.

Verified by flipping it

I patched the two resources in the E2E zone and re-ran the same probe:

Probe	Before	After
re-exchange for the same resource	invalid_grant	succeeds
re-exchange for a different resource	invalid_grant	succeeds, aud = downstream
impersonate directly for that resource	succeeds	succeeds
unregistered target	invalid_target	invalid_target

So the "impersonated tokens are not re-exchangeable" claim was entirely an artifact of our own provisioning. With an owner set, an impersonated token re-exchanges normally.

Worth stating plainly since the old text called it anti-laundering: re-exchange confers nothing the caller couldn't already get. The same client can impersonate that user directly for the downstream resource, which the table above shows succeeding both before and after. Nothing is escalated.

ECO-297 is closed, without a browser login

The production grant path is a live row now. An inbound caller token is exchanged for one token per downstream resource, with an impersonated token standing in for the verified inbound token:

grant-decorator  1: the grant path exchanges an inbound token for every resource  PASS  status=success, both resources granted

Subject is preserved across the hop, verified separately (sub identical on both issued tokens). The checklist assumed this needed one interactive browser login; it needed the owner field.

Two live rows corrected

The re-exchange row asserted a refusal and labelled it an impersonation invariant. It becomes onward delegation succeeding, asserting the subject survives the hop.

The malformed-subject-token row claimed invalid_grant in its label while its body accepted any OAuthError. It now asserts invalid_request, which is what a zone actually emits. That makes it a real divergence from the spec and restores the half of the earlier error-code finding that was correct: the spec lists invalid_grant for a rejected subject token, and a malformed one yields invalid_request. The half I retracted stays retracted, since invalid_target is emitted exactly as specified.

The a2a example had the same omission

examples/a2a-delegation/bin/live registers its own Agent B resource and also left the owner unset, so agent A's exchange leg would fail against a zone that harness provisioned itself. Fixed the same way.

Its README also blamed the impersonation fallback on the zone refusing to exchange a token. The real reason is narrower: bin/live sends no inbound bearer token, so agent A has nothing to exchange. Corrected.

Verified

bin/live-e2e: 13 of 13 pass, 0 fail, 0 skip. examples/a2a-delegation/bin/live: 6 checks pass (act still nil, unchanged finding). bundle exec rake: 166 examples, 0 failures, RuboCop clean.

Live-zone state changed: the two resources in zone rhq9vepbjm8pfld7n2pz2lgys5 now carry application_id. That was the point, and re-running bin/provision is idempotent.