Summary

  • The 2 November ACE working-group revision describes an optional Short Distribution Chain: the authorization server can upload an access token to the resource server on the client's behalf and report the result. It remains an Internet-Draft.
  • New Section 10.1 expects timestamped server logs of token requests, uploads and token life cycles; resource-server logging is desirable within memory, compute and energy limits.
  • Servers must keep operational secrets out of logs. Before sharing with external managers, the designated storage point should redact client and server metadata that would allow tracking, unless a specifically authorized recipient is entitled to it.

A shorter token journey leaves a longer paper trail

In the basic ACE framework, a client asks an authorization server for permission, receives an access token and carries it to the resource server. The Short Distribution Chain proposal moves that delivery to the authorization server. It can upload the token directly, tell the client whether it succeeded, and hand the token back if the upload failed. Some deployments can configure the server to issue and upload tokens for clients that do not know the token exchange exists. The link between the two servers must be protected.

That change makes the authorization server a better witness. The 2 November revision of the ACE working-group draft adds an operational section absent from the previous version. It expects timestamped logs for token requests, issuance, upload outcomes, expiration and revocation, plus client and resource-server registration. At the resource server, logs of token acceptance, storage, deletion and failed access are desirable as its limited resources allow. An operator now has a way to ask whether a token was merely issued, actually uploaded, accepted, later removed or used against a protected resource.

The witness can also become a tracker. Addresses and authentication-credential identifiers may tie a client or resource server to interactions across several parties. The draft allows a designated storage point to hold, manage and share logs with authorized external management applications. It says operational secrets and confidential key material must never enter those records. For shared logs, the storage point should remove privacy-sensitive elements that make device tracking easier; a specific authorization under an enforced privacy policy can justify an exception.

Log retention, detail and data models remain application and operator choices.

The distinction between the words matters. The prohibition on logging secrets is a MUST NOT. Redaction before external sharing is a SHOULD, with an explicit exception. Neither sentence sets a universal retention period. The new section gives managers enough evidence to diagnose a missing permission while asking them to decide how much device history they really need to see.

This is a draft design, with no production uptake or misuse count in the text. Its governance question is already practical: if the authorization server delivers a token for a client, which operator can later inspect the resulting trail, and how much of the client's identity travels with it?

Original sources