In the meeting, I proposed that we make the use of JSON in ACME
something that can be easily shared across multiple Web Services.
In a few years time we are quite likely to have multiple JSON Web
services that people want to use together. Implementing them as a
suite is going to be easiest if there is a consistent style. Some of
the encoding choices in ACME right now make implementation in
statically typed languages rather less convenient than they could be.
In particular it is really difficult to parse data streams when the
type descriptor for an object is a field inside the object that can
occur last rather than being first on the wire.
Looking at the impact of the changes in the spec, I don't think the
changes should delay things as I think they actually make the document
easier to read. At the moment there are things in sections 5 and 6
that seem in the wrong place. Promoting the "type" field to be the
name of the thing makes section 7 a lot clearer.
I can make the edits myself of course. But thought I would check up on
the nature of the edits first and see if my approach was acceptable.
I see the following areas needing change:
5.3. Request URI Type Integrity
Reword to specify the mapping of requests onto JSON messages, each
request is a single object consisting of one field whose tag specifies
the request type and whose value is an object containing the request
data.
Move table from here into section 6. Because section 5 should specify
the layering, it should be ACME agnostic. Later on, this is the
section we will pull out and build on as a re-usable element in other
protocols (e.g. LURK).
5.X Discuss GET vs POST
While we are about it, there should be some grounding in section 5 for
the GET/POST distinction made in section 6.
I think the document as a whole would be cleaner if these were set out
as two options in section 5 then section 6 describes which are
assigned to which.
6. Certificate Management
One of the things I found very confusing when trying to implement was
that there are tables in 5.3 and 6.1 that seem to have the same
information but obviously don't as one has eight entries and the other
has six.
I think these need to be merged.
Example now becomes:
{ "new-reg" {
"contact": [
"mailto:[email protected]";,
"tel:+12025551212"
],
"agreement": "https://example.com/acme/terms";,
"authorizations": "https://example.com/acme/reg/1/authz";,
"certificates": "https://example.com/acme/reg/1/cert";,
}}
6.1.2 Authorization Objects
The structure of an ACME authorization resource is a JSON
object with exactly one field that specifies resource type and whose
value is an object containing the resource parameters.
{
"status": "valid",
"expires": "2015-03-01T14:09:00Z",
"identifier": {
"dns" : {
"value": "example.org"}
},
"challenges": [
{
"http-01" : {
"status": "valid",
"validated": "2014-12-01T12:05:00Z",
"keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE"
}}
],
}
7. Identifier Validation Challenges
Here, just delete the 'type' fields and instead put the type value in
the section headings.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
