On Sun, Oct 2, 2016 at 7:46 AM, Richard Barnes <[email protected]> wrote: > I'm worried that we're losing a lot of useful, clear semantics here in > order to save a few bytes. > > I understand the impulse here; it is challenging to have multiple status > values that could conflict with each other, and it's a pain for the client > to have to go fetch a separate authorization resource to find out what it > has to do. That doesn't mean that we've gotten the semantics wrong; we've > just put the bits in the wrong place. > > If we want to do something here, I think the right way to think about it > is as "inlining" the authorization document in the authorization > requirement, just as challenge resources are inlined into authorization > resources. That is, we would have "authorization" requirement objects > contain the contents of the authorization resource, in addition to a URL > for the authorization resource. > > However, I'm not really sure that even that is worthwhile. Consider that > authorizations can be re-usable for multiple applications; we envisage > clients being able to authorize a bunch of domains, then issue certificates > for arbitrary combinations. It's wasteful to replicate the authorization > document in each application that uses already-valid authorizations, in > terms of bytes on the wire, but also in terms of the server's state storage > (if it stores the authorizations in the application object) or processing > (if it re-assembles them each time). At the very least, we need to have > authorizations continue to be independently addressable in order to > indicate clearly that the same authorization is being used for different > applications -- a need that does not necessarily apply to other types of > requirement objects. > > In any case, we should not lose the semantic distinction between "proving > that you control an identifier" and other things a server requires the > client to do. >
+1 I think this is most obvious in the case of payment. A CA might ask me to prove that I own the identifier once but pay each time. This seems like it should be first-class. -Ekr > This PR also removes two important pieces of functionality: > - The generic OOB requirement type - Would need to be replaced by new > authorization types > - The ability of the protocol to cleanly support new identifier types; > instead of just defining a new identifier type and some challenges, you > need to copy / paste the whole definition of the dns-name challenge. > > So my preference here would be to be more targeted: > - Clarify that the "status" of an "authorization" requirement MUST equal > the status of the underlying authorization > - Possibly allow inlining of the authorization (not require, for the reuse > reasons above) > > > > > On Thu, Sep 29, 2016 at 5:28 PM, Ted Hardie <[email protected]> wrote: > >> On Thu, Sep 29, 2016 at 1:50 PM, Jacob Hoffman-Andrews <[email protected]> >> wrote: >> >>> >>> This also makes sense. I think URIs make more sense, rather than >>>> defining a new namespace. And the URIs can contain more information >>>> about the type. What do other folks think? >>>> >>>> >>> I'm a little confused about the proposal, especially how the URI would >>> contain more information about the type. Would you mind fleshing this out >>> a bit? >>> >>> Something like this: >>> >>> Servers that create authorization objects with a non-standard type >>> should provide a URL as the type string. This allows non-standard types to >>> be created in a well-defined namespace, to avoid conflicts. Visiting the >>> URL in a web browser should result in a human-readable web page describing >>> the non-standard authorization type. >>> >>> However, I'm very open to other suggestions! >>> >> >> Well, I guess I have two thoughts here. The first is that if we do want >> to shift to URIs, then we should move DNSname to also being a URI (a URN at >> IANA or an IANA registry entry). If the client recognizes it, then it >> doesn't need to dereference the page, as the content is guaranteed to be >> the same (especially so in the case of URNs), but it is getting the same >> sort of identifier for standard and nonstandard types. >> >> But I'm not sure that this is the right direction, as I worry that we >> might lose interoperability over time. For out-of-band authorizations, I >> think we could use a single common type and an additional field for >> dereferencing the out-of-band steps. But for new general mechanisms, it >> would be useful if the client knew from examination whether it could or >> should use the authorization type. If service A and service B use >> different URIs for the same mechanism, you have the possibility of a client >> not recognizing that it can use service B. >> >> Imagine for a second that someone creates a method to use an entry in a >> block chain as an authorization mechanism; if more than one service wants >> to use the method the 2nd and later either have to refer to the type using >> the first's URI or making up new URIs that aren't automatically recognized >> by clients built in response to the first. >> >> I agree with the need to collision, but I'm not sure that we have likely >> collisions unless we try to differentiate each out-of-band set of steps >> into types. That doesn't seem that useful to me, personally. >> >> Just an initial reaction, >> >> Ted >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
