Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad <[e-mail]>]

I have much the same problem.  While a client could find an AS which would
authenticate the client, I don't know how the client would establish any
degree of trust in the AS which is going to give it tokens.  If you have
already put a local public key for the AS into the client, then you might as
well put in a name for the AS as well.  I suppose you could get by with a
shared secret but that does not seem to be a good way to build up the
system.

Jim


-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Monday, May 4, 2020 9:09 PM
To: Olaf Bergmann <[e-mail]>
Cc: Peter van der Stok <[e-mail]>; Jim Schaad
<[e-mail]>; [e-mail]; 'Ace' <[e-mail]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:
> Hi Peter,
> 
> Peter van der Stok <[e-mail]> writes:
> 
> > When I want to access an OCF device I can find its IP address 
> > through service discovery (rfc7252 section 7) using an rt-value 
> > registered at the IANA core parameters registry.  For example, when 
> > I want to initialize the AS I have to type in the IP address of the 
> > AS.  From that moment on keys and certificates can be compared to 
> > continue initialization.
> >
> > Using service discovery can automate that process.
> >
> > My request is that authz draft registers an rt-value in core 
> > parameters registry for service discovery of the AS, unless a 
> > different process has already been established for AS initialization.
> 
> That is exaclty what originally has been done in section 9 of 
> draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the 
> process.

I think I'm still a little confused as to what good being able to "discover"
that the network says something is an AS is, without some prior trust and/or
key material for that AS.  How would the necessary trust be established as
part of such a discovery scheme?

Thanks,

Ben