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