> Meiling, Yuning, > > Before I open a PR I need one thing settled, because the two answers > I have point in opposite directions and whichever I build will > conflict with the other. > > Yuning wrote on #15 yesterday that the scenario is better handled > inside UC1, that UC1 has already been updated to cover it, and that > #15 can be closed as merged. > > Meiling wrote this morning that a new standalone use case is the > clearest approach, and asked me to open a PR in that shape. > > I am happy to write either. Tell me which and I will send it. > > For what it is worth, my own view sits closer to Yuning's, and I want > to say why in case it helps you decide rather than just defer. > > The three points Yuning added to UC1 are the right ones - binding > approved constraints to later execution, preserving the admission > basis through to the endpoint, and verifying execution-time evidence > before the action takes effect. Those cover the gap. If they are in > UC1 already, a separate use case would restate the same requirements > under a different narrative, and the catalogue gets longer without > getting clearer. > > The one thing I would check before closing #15 is whether the UC1 > text keeps the distinction visible. The failure is not that the > agent lacked authority, and not that the wrong principal acted. The > agent had authority and the specific action was never approved by > anyone. If UC1 now carries that as a stated requirement rather than > as narrative context, then #15 is genuinely covered and I have no > objection to closing it. > > If instead you want it standalone because the point gets lost inside > UC1, that is a reason I would accept, and I will write it that way. > > On Gap C, the enrollment dependency, Yuning is right that it is > cross-cutting rather than UC1-specific. It sits under every use case > in the catalogue where a key is resolved to a person. If it is > useful I can propose short text for it as a cross-cutting concern > rather than attached to any single use case. > > Mohamad
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
