On Wed, Oct 23, 2024 at 01:02:26PM +0200, Q Misell wrote: > > Automation systems would never receive a RSC without first having sent > > out instructions about what's expected in the RSC's payload. > > Whilst this is on the surface correct, it misses the point. Consider the > following: > > 1. System A expects an RSC in format A
The RSC format has been specified in RFC 9323 > 2. System B is unaware of format A, and is thus unaware of the > consequences of signing an RSC in format A > 3. User A asks System B to create an RSC in format A > 4. System B happily obliges, not knowing the consequences of what it is > signing > 5. System A accepts the RSC from User A - even if User did not have the > required permissions within the organisational scope of System B to do so This is an issue internal to Organization B; an additional field in the RSC payload will not resolve this type of issue. Whether the payload is RFC9323-compliant or RFC9323bis-compliant, the moment system B 'blindly' signs over a set of bytes they ought not to sign over from an organisational scoping perspective, B is dead in the water anyway. If Organisation B has concerns in this space, they can internally specify a number of purposes they will / will not sign over as part of the internal signing request. > > I suspect purpose can be derived from context in which the RSCs are > > sent/received. > > Independent systems can derive different expected purposes from > context if we're not explicit about it. Both systems are participating in processes outlined in Peering API. Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
