Introduce an AS-managed deferred_object_id for Deferred Flow Retrieval

[nardil]

Current behavior

In the current deferred flow, when the requested attestation/dataset is not immediately available, the identifier used to retrieve it later is derived from the jti value emitted by the Credential Issuer. In practice, clients use this jti-based identifier in subsequent polling/retrieval calls to fetch the final dataset/attestation once it becomes available.

Problem

This approach is not ideal for two main reasons:

• Unwanted coupling: jti is an Issuer-side token identifier. Using it as the retrieval/correlation identifier ties the Authorization Server (AS) deferred flow to an Issuer-internal construct.
• Lack of AS control: In a deferred flow, the AS should be able to define and govern the correlation/retrieval handle independently, without relying on the Issuer’s token semantics.

Overall, using jti as a deferred retrieval identifier makes the flow less practical and harder to evolve, and it blurs responsibilities between AS and Issuer.

Proposed solution

For deferred responses, the AS should explicitly return an opaque retrieval handle generated and managed by the AS. This handle is then used in subsequent calls to retrieve the dataset/attestation. When the dataset becomes available, this identifier maps to (or remains) the anonymous dataset identifier.

Suggested response shape for deferred cases:

{
  "interval": 600,
  "deferred_object_id": "12345-67890-abcdef"
}

Where:

• deferred_object_id is an opaque identifier created and managed by the AS.
• Clients must use deferred_object_id for later retrieval/polling operations.
• The AS remains the authority for correlation in the deferred flow, removing dependency on the Issuer’s jti.

Benefits

• Decouples deferred retrieval from Issuer token internals (jti)
• Restores clear ownership of deferred correlation to the AS
• Improves maintainability and future extensibility of the deferred flow

[peppelinux]

I am ok with that, I had some concerns too about a potential misuse of jti, according to its original purpose

@fmarino-ipzs ^

[m-basili]

@nardil,

jti (of the Agid-JWT-Signature present in the e-service request) is not used in the subsequent calls. The jti is used by the Authentic Source to notify through Signal Hub the availability of the Credential Dataset(s). The objectId of the signal is valued with the value of this jti (link).
The next call(s) to the Authentic Source will be made as if it were any other call (with a new jti).

We could introduce in its place a "deferred_object_id" managed by the Authentic Source, in this case this new claim must be used to value the objectId claim of the Signal.
However, there will be no correlation between the first and subsequent calls to the authentic source.

[nardil]

Hi @m-basili, thanks for the clarification

when we referred to “subsequent calls”, we meant the Credential Issuer follow-up calls to retrieve the Credential Dataset not the next e-service request from the Issuer to the Authentic Source, which indeed will carry a new jti.

Given this, our concern remains: today the Signal Hub notification uses the jti from the Agid-JWT-Signature of the initial request as objectId. This effectively makes the jti the only handle to reference the deferred result. This also highlights an additional edge case: if the Credential Issuer sends another request before the dataset is available, there is ambiguity on which jti should be used / associated with the dataset.

For this reason, introducing an AS-managed opaque handle (e.g. deferred_object_id) still seems beneficial: it would provide a stable identifier for the deferred dataset lifecycle, to be used as objectId in the Signal and as reference for the Issuer retrieval step, without relying on token-specific jti semantics.