Hi John, Replies inline
/Ludwig > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1. It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2. The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
