Hi Ilari,
> This impiles that if pre-authorization is not supported, newAuthz better > be absent (this is also useful for detecting pre-authorization support if > the client can use it somehow). > I think this should be at least a SHOULD. You're right. My intention is to make the presence of that field an indicator of pre-authorization support (or lack thereof). I'll update to a SHOULD in my PR since I agree that maps better. Thanks! On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote: > > In Section 7.4.1 "Pre-Authorization" the spec says: > > > > If a CA wishes to allow pre-authorization within ACME, it can offer > > > a "new authorization" resource in its directory by adding the field > > > "newAuthz" with a URL for the new authorization resource. > > > > > > That text indicates that the CA may wish to *not* support > pre-authorization > > in which case the "newAuthz" resource will not be present in the > directory. > > E.g. the Let's Encrypt ACME v2 directory[0] does not include this > resource. > > > > I think this should be further emphasized in Section 7.1.1 "Directory" > > since this is where a developer is likely to look first when trying to > > determine what directory fields can be assumed present. > > > > I opened a PR to add a small note about this to Section 7.1.1: > > https://github.com/ietf-wg-acme/acme/pull/384 > > > > This is perhaps a step past the line of being strictly editorial. I would > > appreciate if anyone with objections raise them on-thread over the next > few > > days. > > Why MAY? If implementation does not support some functionality that an > endpoint is exclusively for, it better omit that endpoint. This impiles > that if pre-authorization is not supported, newAuthz better be absent > (this is also useful for detecting pre-authorization support if the > client can use it somehow). > > I think this should be at least a SHOULD. > > > > -Ilari >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
