From Section 9.7.1 :
"This registry lists field names that are defined for use in ACME
account objects. Fields marked as “configurable” may be included in a
new-account request."
"Client configurable:...."
"Initial contents: The fields and descriptions defined in Section 7.1.2"
1_ The section is unclear, if it is only for account objects listed in
Section 7.1.2 then "externalAccountBinding" should not be listed or
section 7.1.2 is missing "externalAccountBinding",which is defined as
optional in Section 7.3 , along with "onlyReturnExisting" ,so should
Section 9.7.1 contain other mentioned fields in other account sections
like "oldKey" in (Section 7.3.5 Account Key Roll-over) ? ....!!??
2_ "status" is listed as not configurable while it is configurable in
(Section 7.3.6. Account Deactivation) .
From (7.3.2. Account Update) :
"If the client wishes to update this information in the future, it sends
a POST request with updated information to the account URL. The server
MUST ignore any updates to the “orders” field, “termsOfServiceAgreed”
field (see Section 7.3.3), the “status” field (except as allowed by
Section 7.3.6), or any other fields it does not recognize. "
So basically server should check at first for "contact" field changes
for every POST request and skip anything else, if that is the case then
this logic should be mentioned in clear way in earlier sections, on
other hand some changes to this sections might be enough to fix this and
remove any confusion, so i suggest changing that paragraph to the
following :
"If the client wishes to update this information in the future, it sends
a POST request with updated information to the account URL. The request
MUST NOT contain "orders" field, “termsOfServiceAgreed” field, “status”
field or "externalAccountBinding" field, and should contain "contact"
field with the updated account information. If the server accepts the
update, it MUST return a response with a 200 (OK) status code and the
resulting account object."
There is no need to mention (Section 7.3.6) as it is very clear, all
responses from POST or POST-as-GET to a deactivated account MUST be
unauthorized error response.
Last thing : (Sections 9.7 New Registries) has sections 9.7.1 , 9.7.2
and 9.7.3 describing Account Objects, Order Objects and Authorization
Objects and that i think cover all, except for 7.6. Certificate
Revocation identifiers which left out , "certificate" and "reason"
fields are new and deserve to be registered.
Kind regards,
K. Obaideen
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
