Hi Christian, Thank you for your input. I like your idea on Figure 5, to make the DO talk to the AS directly rather than sending a large payload to the client. 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. We could elaborate this step where we can send the large signed statement to the AS to register the client to ACE framework. Later as you suggested, the DO can POST a link pointing to the RS. This step could be considered as a delegation step as well, from the DO to its trusted client. Yes, I agree this would be a better protocol flow for the constrained client. 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.
Yes, indeed with this we could at least solve the AS validation problem and the client can avoid the initial unauthorized resource request to RS. Yes, as part of the POST link we must include AS URI, the AS's credential, the audience and scope and the key ID (or Client ID(there is a similar step in OAuth dynamic client registration step as well)) that the AS assigned. 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. Yeah, the two solutions in section 4.2 require the RS and client can query another online entity when connecting with each other. With this new approach, we no longer need them. 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. We can meet in Paris, me and Olov will participate in person:) L1:draft-ietf-ace-workflow-and-params-01 - Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework <https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/> /Sree *SREELAKSHMI V S* PhD Student in Industrial Electronics Luleå University of Technology (LTU) 97187 Luleå, Sweden. 3822 On Fri, May 17, 2024 at 12:23 PM Christian Amsüss <christ...@amsuess.com> wrote: > 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 >
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
