Observed with @aauth/agent 3.0.2 from packages-js 7bd31a5.
A Resource advertised:
{"additional_signature_components":["content-type","content-digest","idempotency-key"]}createAAuthFetch() sent the initial POST with this Signature-Input:
sig=("@method" "@authority" "@path" "content-type" "signature-key" "content-digest");created=...
The request correctly covered the body fields, but omitted idempotency-key, so the Resource refused it before the person-token challenge. The createSignedFetch documentation says Resources declare their needs through additional_signature_components, but createAAuthFetch neither resolves /.well-known/aauth-resource.json nor accepts validated Resource metadata/components from its caller.
Expected: before the first Resource request, either resolve and cache the Resource metadata or accept an explicit validated metadata/components input, then include every declared component in the signature. Moving a replay key into a signed body works for that one application, but does not solve general Resource-declared headers.
This is adjacent to #20 but distinct: #20 concerns the fetch authorize subcommand and its authorization endpoint/person-token leg; this affects the main @aauth/agent fetch path and the first signed Resource request.
Observed with @aauth/agent 3.0.2 from packages-js 7bd31a5.
A Resource advertised:
{"additional_signature_components":["content-type","content-digest","idempotency-key"]}createAAuthFetch()sent the initial POST with this Signature-Input:The request correctly covered the body fields, but omitted
idempotency-key, so the Resource refused it before the person-token challenge. ThecreateSignedFetchdocumentation says Resources declare their needs throughadditional_signature_components, butcreateAAuthFetchneither resolves/.well-known/aauth-resource.jsonnor accepts validated Resource metadata/components from its caller.Expected: before the first Resource request, either resolve and cache the Resource metadata or accept an explicit validated metadata/components input, then include every declared component in the signature. Moving a replay key into a signed body works for that one application, but does not solve general Resource-declared headers.
This is adjacent to #20 but distinct: #20 concerns the
fetch authorizesubcommand and its authorization endpoint/person-token leg; this affects the main@aauth/agentfetch path and the first signed Resource request.