Unless you believe that an alternative format is ever desirable. CBOR
for version 2 might be a terrible idea, but I know the IETF well
enough not to rule that out entirely.
On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes wrote:
> I also note that there's no issue with Accept if we require the use
I also note that there's no issue with Accept if we require the use of the
Flattened JSON serialization.
https://i.imgflip.com/25r2ui.jpg
https://github.com/ietf-wg-acme/acme/pull/410
On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson
wrote:
> That's a bit silly. I'll follow-up with httpbis. I t
That's a bit silly. I'll follow-up with httpbis. I think that's an
error, though probably only an error of omission. 7694 was so fixated
on solving the content-coding issue, it neglected the obvious
accompanying fix.
On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes wrote:
> How about Accept? It
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
wrote:
> 415 is for the case where a client provides bad request content, s
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" wrote:
How about this: Specify a defaul
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" wrote:
The lengths of the emails in this thread illustrate the complexity risk
here :)
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 librarie
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
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
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 "supportedSer
On Fri, Mar 02, 2018 at 17:29:04 -0500, Richard Barnes wrote:
> > On Mar 2, 2018 9:47 AM, "Felipe Gasper" wrote:
> >
> > Could there be some way of using a header like “Accept” for a server to
> > indicate whether it supports jose, jose+json, or both?
> On Fri, Mar 2, 2018 at 2:29 PM, Logan Widick
On Thu, Jan 04, 2018 at 00:07:34 +0100, Jörn Heissler wrote:
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.6.2
> states:
>
> In the examples below, JWS objects are shown in the JSON or
> flattened JSON serialization
>
> All examples in the ACME specification
I don't really have a preference for which serializations are used, as long
as all ACME implementations (regardless of the programming language used)
can support the chosen serializations, and new serializations can be added
later if necessary.
When I searched the listings on GitHub and jwt.io a m
> If you have suggestions here, a PR would be welcome. TBH, this issue
> kind of makes me want to reverse course and say "all flattened JSON",
> but I get the sense that other folks disagree?
I'd be very much in favor of "all flattened JSON." When we started ACME,
I think there was some concern t
On Fri, Mar 2, 2018 at 2:29 PM, Logan Widick wrote:
> I think the follow-on (#398) includes the Accept header in error responses
> (to requests with unacceptable serializations).
>
Indeed it does!
> Also, there may need to be another follow-on regarding how to serialize
> "nested" JWS instance
I think the follow-on (#398) includes the Accept header in error responses
(to requests with unacceptable serializations).
Also, there may need to be another follow-on regarding how to serialize
"nested" JWS instances (like the externalAccountBinding and the inner JWS
for a key change).
Logan
On
Could there be some way of using a header like “Accept” for a server to
indicate whether it supports jose, jose+json, or both?
-F
> On Mar 2, 2018, at 9:50 AM, Richard Barnes wrote:
>
> Hey all,
>
> I merged #395 last night (thanks, Logan!). While I was reviewing that, I
> noticed that we n
Hey all,
I merged #395 last night (thanks, Logan!). While I was reviewing that, I
noticed that we need to cover the case where the client sends an encoding
that the server doesn't understand. So I've posted a follow-on that adds
an error code and requires its usage. LMK if you have any objectio
I've created a new pull request (
https://github.com/ietf-wg-acme/acme/pull/395) to partially address the
lack of serialization format specification. This pull request requires use
of the Content-Type HTTP header to indicate the serialization format of the
outermost JWS. The pull request also inclu
Last night, I briefly surveyed the listings of JWT implementations on jwt.io.
I could find only a small handful that appeared to support all
serializations, and even fewer that appeared to give programmers control
over what serialization was produced. Thus, assuming jwt.io is a
sufficiently accurat
On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote:
> What do you think of the following:
> Content type application/jose+json: MUST be supported. If used, the JWS
> will need to be in the Flattened or General serialization. Flattened MUST
> be supported; General MAY be supported.
> Conte
To the best of my knowledge, the ACME signature solution was not fully
addressed years ago.
As far as I know, the only requirements for signatures discussed and
explicitly specified in the text of the ACME draft are:
Use JWS signatures (not JCS signatures) over HTTPS
Don't use the "none" algorithm
What do you think of the following:
Content type application/jose+json: MUST be supported. If used, the JWS
will need to be in the Flattened or General serialization. Flattened MUST
be supported; General MAY be supported.
Content type application/jose: MAY be supported. If used, the JWS MUST use
On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
> I am the author of a JOSE library, and have had to deal with
> interoperability issues arising from the multiple serialisations and
> underspecified applications/protocols. Please heed my advice.
>
> Where there is a choice of JSON
Here is a pull request: https://github.com/ietf-wg-acme/acme/pull/382
Let me know what you think.
Sincerely,
Logan Widick
On Wed, Jan 3, 2018 at 6:21 PM, Logan Widick wrote:
> This looks good to me.
>
> As for using JOSE implementations that lack support for the JSON
> serialization formats (
This looks good to me.
As for using JOSE implementations that lack support for the JSON
serialization formats (and only support the compact one), is there an RFC,
Internet-Draft, or similar document with an explanation of the conversion
process already prepared (that can simply be thrown into the
On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> Hello and happy new Year!
>
> I've found an inaccuracy in the ACME specs.
>
> https://tools.ietf.org/html/rfc7515#section-7 states:
>
> Applications using this specification need to specify what serialization
> and serializ
I agree that a serialization format (or set of formats) would need to be
standardized. Related thread:
https://www.ietf.org/mail-archive/web/acme/current/msg01690.html
Sincerely,
Logan Widick
On Wed, Jan 3, 2018 at 5:07 PM, Jörn Heissler
wrote:
> Hello and happy new Year!
>
> I've found an ina
28 matches
Mail list logo
