It seems that this could be exposed by the IdO (or by the proxy IdO) by means of a new ACME resource.

I'm not sure this is useful, because it needs to be used by the CDNI client (which doesn't want to implement ACME). Also the CDNI client might need parts of this configuration to access the IdO's endpoint.

I was trying to step back a bit from CDNI and look at the STAR delegation interface as a whole.

ISTM that configuring the delegation is part of the STAR delegation functionality. So, it seems logical for the configuration bits to come in the same package as the rest of the interface. And because we need to stay loyal to REST, making the configuration a new resource in the object model would seem like the obvious way forward.

Zooming in, from the CDNI (or any other consumer) point of view, bootstrapping the delegation comes bundled with the associated ACME account setup (e.g., via a new delegations attribute):

   HTTP/1.1 201 Created
   Content-Type: application/json
   Replay-Nonce: D8s4D2mLs8Vn-goWuPQeKA
   Link: <https://example.com/acme/directory>;rel="index"
   Location: https://example.com/acme/acct/evOfKhNU60wg

   {
     "status": "valid",

     "contact": [
       "mailto:cert-admin@example.org",
       "mailto:admin@example.org"
     ],

     "orders": "https://example.com/acme/acct/evOfKhNU60wg/orders”,
     “delegations": "https://example.com/acme/acct/evOfKhNU60wg/delegations”
   }

The delegations directory is read-only for the NDC. Each file (resource) contains the CSR template(s) to use for a specific delegation.

Then, in the CDNI Metadata, the delegation in use can be simply expressed as a URL, e.g.: https://example.com/acme/acct/evOfKhNU60wg/delegations/1 pointing at the specific config.

The same config URL shall be included in the request for the delegated certificate to point to the configuration under which this request is made.