How about Accept? It looks like 7694 gives the server a way to specify encodings, but not the content type. But 7231 says that Accept only replies to response media types.
On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson <[email protected]> wrote: > 415 is for the case where a client provides bad request content, so yes. > See rfc7694 for details. > > 406 is for failed conneg. Not something you expect to see much here. > > > On 5 Mar. 2018 09:25, "Richard Barnes" <[email protected]> wrote: > > The lengths of the emails in this thread illustrate the complexity risk > here :) > > In the interest of simplicity, I would really like to stick to Flattened > JSON unless someone has **strong** objections. > > Logan, to your point about library compatibility, two notes: (1) it's OK > if we front-run libraries a little. It's not hard for libraries to > upgrade; this is only formatting, no crypto changes needed. (2) > Empirically, this must not be too big a blocker for people, since as Jacob > notes, Let's Encrypt only supports Flattened JSON right now and they've got > a bunch of clients talking to them. > > As far as headers / response codes: You're correct that 406 is wrong / 415 > is right. But ISTM that Accept is still the right header to say what is > right. So the server should return 415+Accept. Copying Thomson to check > our work here. > > --Richard > > On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick <[email protected]> > 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 < >> [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
