On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick <[email protected]> wrote:
> According to the draft minutes, as of the end of IETF 98, the plan was to > eliminate the "up" link relation from authorization to order since an > authorization can belong to multiple orders and nobody seemed to rely on > this relation. However, I still see this "up" relation on GitHub. Is the > plan still to remove that "up" relation, has the plan changed, or is the > plan to wait and see if anyone uses the relation first? > We just haven't gotten around to implementing it yet :) Here's a PR: https://github.com/ietf-wg-acme/acme/pull/298 > As for the "up" link relation from challenge to authorization (not > mentioned on slides), this could encounter a similar problem. As a simple > example to illustrate the potential problem, assume a server issues an > order with two authorizations: one authorization for (http-01 or dns-01), > and another authorization for (tls-sni-02 or dns-01). To prevent the client > having to complete the same challenge twice, assume that the server used > the same dns-01 challenge instance for both authorizations. For the common > dns-01 challenge, where does the "up" relation point to? This could become > a more significant issue as new identifiers, challenges, etc. are added in > the future. How should this be addressed? > Why would a server do what you're saying? It seems like the construct you propose basically just takes the OR combinations of challenges in the individual authz and ANDs them. We had agreed a long time ago that a single OR layer was sufficient for all known use cases. And if you want to create an AND, this is about the least elegant way you could create the AND, vs. say a conjuction challenge type, or the "combinations" array we had before. Given that, I'm comfortable saying that each challenge belongs to exactly one authz. --Richard > > Sincerely, > > Logan Widick > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
