Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[Seitz Ludwig <[e-mail]>]

Hi John,

Replies inline

/Ludwig

> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of John Mattsson
> Sent: den 5 september 2020 14:53
> To: [e-mail]
> 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.