There needs to be a stronger benefit demonstrated than this. As Richard
says, implementing flat serialization is near trivial. Rather than add more
complexity, settling on precisely one format solves the problem neatly.
On 5 Mar. 2018 02:43, "Logan Widick" <logan.wid...@gmail.com> wrote:
How about this: Specify a default format (either "application/jose" for
Compact Serialization, or "application/jose+json" with Flattened
Serialization - I have no preference which one), with optional support for
other formats if needed? Even with JOSE libraries that don't support all
serializations and/or don't provide control over which serialization is
used, a programmer would at least need to know (or experimentally find out)
if a JSON serialization or if the compact one is being produced. If a JSON
serialization is selected as the default, a programmer should be able to
convert between the two JSON serializations easily as needed before and/or
after using a JOSE library. If a JSON format is declared as the default but
the JOSE library only has the compact one, or vice-versa, conversion before
and/or after the JOSE library would be more complex but should still be
doable with guidance.
The directory meta item could be defined as something like:
- supportedSerializations: An array of supported serialization formats
as described in {{jws-serialization-formats}}. If this is not specified,
assume that the server only supports [insert selected default here].
Then, the JWS Serialization Formats section could be changed to something
like the following:
The JSON Web Signature (JWS) specification {{!RFC7515}} contains multiple
JWS serialization formats. When sending an ACME request with a non-empty
body, an ACME client implementation SHOULD use the HTTP Content-Type
{{!RFC7231}} header to indicate which JWS serialization format is used for
encapsulating the ACME request payload.
Each serialization format defined for use in ACME is described with a
content type, and a series of ACME-specific restrictions on root JWS and
nested JWS instances. A "root JWS" is a JWS used to encapsulate an entire
ACME request payload, and a "nested JWS" is a JWS contained within the ACME
request payload (such as the "externalAccountBinding" described in
{{external-account-binding}} or the "key-change" object described in
{{account-key-roll-over}}). Below are the JWS serialization formats that
are defined for use in ACME:
[same list as before but with the default format coming first]
If no Content-Type is provided, the default serialization type is [insert
selected default here]. Servers MUST support [insert selected default
here]. [NOTE: If a JSON format is selected as the default, say that a
server SHOULD support the other JSON format.] A server MAY support
additional serializations, such as [insert serialization(s) not picked
here], by including a "supportedSerializations" field in the directory
"meta" object as described in {{directory}}.
If a server receives a request using a serialization it does not support,
the server MUST send a response with HTTP status code 415 (Unacceptable
Media Type) and a problem document with error type
"unsupportedSerialization". This problem document SHOULD contain a
"supportedSerializations" array of strings indicating the acceptable
serialization content types.
[TODO: If a client uses the General JSON Serialization but it turns out the
server only supports the Flattened JSON Serialization (or vice-versa),
explain that a 415 response indicates that the client will need to switch
JSON formats]
[TODO: Insert a sentence or two specifying what happens if a supported
serialization is used but the serialization is malformed? Should this be
400 Bad Request + malformed error code + supportedSerializations?]
In the examples below, JWS objects are shown in the Flattened JSON
serialization, with the protected header and payload expressed as
base64url(content) instead of the actual base64-encoded value, so that the
content is readable. [Example readability is a very high priority
regardless of which serialization format is actually chosen as the default,
and the current convention of Flattened JSON + base64url(content) is about
as readable as it gets, so I don't think any changes will need to be made
here]
On Sun, Mar 4, 2018 at 8:33 AM, Jörn Heissler <acme-sp...@joern.heissler.de>
wrote:
> On Sun, Mar 04, 2018 at 07:45:36 -0600, Logan Widick wrote:
> > Good catch. Should it be 415 (Unsupported Media Type) plus which of the
> > following (or which combination of the following):
> >
> > - A new problem document field (tentatively named
> > "supportedSerializations": an array of media type strings)?
> > - A new directory field (tentatively named "supportedSerializations":
> an
> > array of media type strings)?
> > - Should this go in the directory's "meta" object, or in the
> > directory object itself?
> > - A HTTP header?
> > - Something else?
>
> I like the directory approach with meta. Then a client could
> use this information before sending the first POST. Else the client
> would need to change an internal state after receiving the error
> message. For my own client, I'm planning to support the OpenPGP smart
> card. It takes 3 seconds to generate a signature. If a signature is
> wasted to find out that the default serialization is not supported, it
> would be annoying. Having to write a configuration file "use compact by
> default for CA foo" would be stupid too.
>
> This, and the problem document field. "supportedSerializations" sounds
> fine.
>
> Should the two features be OPTIONAL?
>
> I don't like HTTP headers, it's quite complicated to parse them correctly.
> JSON is so much easier.
>
>
> Or... specify that flattened MUST BE used :-)
>
> Cheers
> Joern Heissler
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
