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 <christ...@amsuess.com> 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 >
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
