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
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
