[Ace] Re: PoA based Device Registration (draft-vattaparambil-ace-wg-poa-device-reg): Support, suggestions

[sree lakshmi <[e-mail]>]

Hi Christian,

The assumption I've been working on is that DO is enrolled to the AS as
> a C. Either the authorizations the AS associates with the DO have a
> "this may be delegated" flag on them, or the AS simply treats itself as
> an RS, where some C (such as the DO) are authorized to utilize the
> "register more clients and transfer some authorizations" interface.


Okay, this is an interesting delegation approach. So here the AS provides
an option to delegate (the delegation flag) to DO, which later makes DO to
delegate the Client. We had a similar discussion on these multi-level
delegations. As I understand, in this way the authorizations the AS
associates with the DO can be delegated to the Client.

As I understand the interfaces we lack, the OAuth dynamic client
> registration covers both the creation of a client and giving it the
> right scope; for ACE I hope we can do something much slimmer.


Sure, we can avoid the client sending the client registration request to
the AS as it is in OAuth dynamic client registration. This is essential for
the constrained nature of the client in ACE. I think the only parameter or
step similar here would be the client id or key id that the AS must provide
the DO upon successful client registration.

>
> The alternative flow can certainly be a good simplification in some
> It would be a *great* simplification if by the mere request from the DO
> it could already issue the token and install it on the RS, and refresh
> it on expiry (for this would free the C from the need to ever actually
> perform the C-AS protocol). Some prior chats indicate that this would
> contradict the ACE architecture where the AS needs to prove that C
> actually has that key, but let's discuss that more. (Personally I don't
> see anything wrong with the AS issuing a token to C blindly -- the token
> will be bound to the key included, and success of EDHOC proves
> possession of that key to the RS).
> If that larger simplification is possible, the data the C receives from
> the DO would not even include AS details any more, but instead would
> contain details of the token response (eg. rs_cnf).

cases.
>

Yeah, I agree, when the client submits the access token req with the
credentials from the req_rs claims pointing to the public key of DO, the AS
can identify the registered client in the previous step. What about the
client id that is obtained from the AS in the previous step (client
registration step)? Shall we have to include it as well? Or is there a way
the AS can recognize the C without this identifier (Client ID or Keyid)? I
have more questions regarding this we can discuss next week.

The credentials are not sent in plain text in EDHOC: the initiator's
> credentials (ie. the token) would only be revealed to the RS after C has
> verified that the RS just presented the right rs_cnf.

Okay.

Multiple entities definitely make this more complex. If the RSes can be
> expresed as a group audience, tools like rs_cnf2 (also from
> ace-workflow-and-params) could help.


I understand, now the last section in the draft talks about the use of PoA
with multiple entities. This might be the right section to elaborate on the
issues and possible solutions with n number of RSs and clients.


/Sree





On Fri, May 17, 2024 at 3:57 PM Christian Amsüss <[e-mail]>
wrote:

> Hello Sree,
>
> On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote:
> > In this draft, we have assumed a pre-established mutual authentication
> > step between the DO and the AS. We haven’t explained it in detail
> > because it is an assumption.
>
> The assumption I've been working on is that DO is enrolled to the AS as
> a C. Either the authorizations the AS associates with the DO have a
> "this may be delegated" flag on them, or the AS simply treats itself as
> an RS, where some C (such as the DO) are authorized to utilize the
> "register more clients and transfer some authorizations" interface.
>
> As I understand the interfaces we lack, the OAuth dynamic client
> registration covers both the creation of a client and giving it the
> right scope; for ACE I hope we can do something much slimmer.
>
> > I read a new alternative protocol flow of ACE (L1), this will even
> > decrease the load on the client side. We can discuss. I will look into
> the
> > CoRE dynlink you mentioned. Will see how we can use it.
>
> The alternative flow can certainly be a good simplification in some
> cases.
>
> It would be a *great* simplification if by the mere request from the DO
> it could already issue the token and install it on the RS, and refresh
> it on expiry (for this would free the C from the need to ever actually
> perform the C-AS protocol). Some prior chats indicate that this would
> contradict the ACE architecture where the AS needs to prove that C
> actually has that key, but let's discuss that more. (Personally I don't
> see anything wrong with the AS issuing a token to C blindly -- the token
> will be bound to the key included, and success of EDHOC proves
> possession of that key to the RS).
>
> If that larger simplification is possible, the data the C receives from
> the DO would not even include AS details any more, but instead would
> contain details of the token response (eg. rs_cnf).
>
> > We also do not like to send the credentials in plaintext, we can go with
> > EDHOC with key identifiers, but I am not well aware of how this works and
> > how to show this in the protocol flow diagram. We can have a discussion
> on
> > this.
>
> The credentials are not sent in plain text in EDHOC: the initiator's
> credentials (ie. the token) would only be revealed to the RS after C has
> verified that the RS just presented the right rs_cnf.
>
> > The problem with bundling of the AS URI, AS credentials, audience, scope;
> > we haven’t thought about it in this way. We had a small thought on
> multiple
> > entities and the scalability of the solution.
>
> Multiple entities definitely make this more complex. If the RSes can be
> expresed as a group audience, tools like rs_cnf2 (also from
> ace-workflow-and-params) could help.
>
> > We can meet in Paris, me and Olov will participate in person:)
>
> Looking forward to that!
>
> BR
> c
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
>