Boulder: ACMEv2: "orders" field missing in account info

[joernheissler]

When I POST an empty update to my account URL I get this:

{
    "id": 5337306,
    "key": {
        "kty": "RSA",
        "n": "<redacted>",
        "e": "AQAB"
    },
    "contact": [
        "mailto:<redacted>"
    ],
    "agreement": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "initialIp": "<redacted>",
    "createdAt": "2018-01-05T01:29:21Z",
    "status": "valid"
}

There is no orders field as required by https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.2

[cpu]

We should implement this field - @jsha @rolandshoemaker ~I remember the question of pagination/truncation of the "orders" field came up before w.r.t this spec feature. What are your thoughts about that here? Should we expect to return all orders? all unexpired orders? The first n unexpired orders?~
I was remembering a point in the spec where the orders field was itself an array of URLs instead of a URL from which one can retrieve URLs.

[buschtoens]

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2

orders (required, string): A URL from which a list of orders
submitted by this account can be fetched via a GET request, as
described in Section 7.1.2.1.

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2.1

Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via GET request. The
result of the GET request MUST be a JSON object whose "orders" field
is an array of URLs, each identifying an order belonging to the
account. The server SHOULD include pending orders, and SHOULD NOT
include orders that are invalid in the array of URLs. The server MAY
return an incomplete list, along with a Link header with a "next"
link relation indicating where further entries can be acquired.

```
HTTP/1.1 200 OK
Content-Type: application/json
Link: https://example.com/acme/acct/1/orders?cursor=2, rel="next"

{
"orders": [
"https://example.com/acme/acct/1/order/1",
"https://example.com/acme/acct/1/order/2",
/* 47 more URLs not shown for example brevity */
"https://example.com/acme/acct/1/order/50"
]
}
````

[buschtoens]

Considering that ACME v2 was scheduled to go live yesterday, is there currently a way to retrieve a list of pending orders?

I'm sure you're busy with getting boulder ready, in order to ship ACME v2 for Let's Encrypt, so please don't feel pressured. I just happened to trip over this again.

[cpu]

@buschtoens We still have not implemented the "orders" field on account objects and we're not considering this a required feature for the V2 launch. I expect it will be a little bit after the launch before we implement it. I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

The best way to watch for progress is to keep an eye on this issue, particularly when it gets assigned to a milestone for a sprint. Thanks for your patience!

[bkromhout]

@cpu, can we expect to see any movement on this anytime soon? The ACME spec draft appears to be quite close to its final form, pending the whole process of making it an actual RFC. While I agree the "orders" field is a convenience, it is still a required part of the spec, yet this has been sitting idle for months now.

[cpu]

@cpu, can we expect to see any movement on this anytime soon?

Unlikely. It's a non-trivial amount of work for a convenience and there is still substantial higher priority work to be done in other areas.

this has been sitting idle for months now.

@bkromhout PRs are welcome.

[mschristiansen]

Is there no alternative to tracking the order ids client side currently?

[jsha]

That's correct.

[colintoal]

It'd be swell if Boulder supported this. Pebble does. I've implemented a client to spec, and this is the last step I need to work around. I'm happy to help if I can.