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

[Christian Amsüss <[e-mail]>]

Hello Sreelakshmi, authors, ACE,

I've read draft-vattaparambil-ace-wg-poa-device-reg-00 and think it
provides a valuable contribution to ACE, especially if it grows to
actually propose an interface to the client registration problem.
I am not sure that the proposed solution has the ideal work flow, but
nonetheless, the WG should concern itself with this. (In particular,
looking at figure 5, I'd rather have the DO talk to the AS rather than
send a relatively large signed statement to the client that the client
then relays to the AS -- the client needs to stay small and carry little
data).

The use case I'm looking into it for is to enable CoRE dynlink [1] (yes
it's long expired, but I still think we should go on with it), where a
constrained device is told to act as a CoAP client and pull or push data
from one resource to another resource, possibly even without
understanding the role of that resource. (My favorite example is that
it'd be used to tell a physical temperature control dial to PUT its
value to a heating control's set-point resource). In practice, picking
up PoA terminology, the device owner POSTs a link pointing to the RS
into the binding site resource of the Client, annotated with some
additional metadata. As the Client is previously unaware of the RS or
its AS, with PoA, the owner would register the Client at the AS, and
then add AS metadata into that POST.

(At least) in this case, the AS validation problem has an almost trivial
solution: As part of the POSTed link (which points to the RS resource),
the DO would include a bundle of the AS URI, the AS's credential, the
audience and scope that it should request and possibly also a key ID
that the AS assigned to the client credentials the DO obtained from the
AS during client registration (as an optimization to not make the client
send its credentials by value -- in my scenario this is all run on
EDHOC, and KIDs make it really really compact).

This way, the unencrypted pre-flight request is completely avoided, and
we don't need any of the two solutions proposed in 4.2 -- instead, the
(AS URI, AS credentials, audience, scope) bundle is conveyed to the
client as part of its mandate to perform some specific task on the RS.

It may even be dangerous *not* to bundle those, if the DO is not just
"the" device owner but just a user that has some control over the
client: If there were multiple such users that both have some authority
over the AS different ASes (or within the same AS), then a less
privileged user might install some low-authorization PoA into the
client, but then direct the client to an RS resource where the
unauthorized initial request redirects the client to use the
high-authorization PoA installed by a different user.

Best regards
Christian

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-14

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom