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. 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
