Dear Aaron and esteemed members, 1. It was good to note that we are planning to simplify the definitions of confidential and public clients in the new specs. However, my thoughts are that instead of these definitions which are open to interpretation, we can work on these two options:
*Option I*: 2. We can define the client applications in terms of trust assurance levels. The trust assurance level will determine the ability of the application to acquire delegated authorization rights (permitted scopes) for a longer duration. (a) *Trust Assurance Level 0*. This is the minimum trust assurance level. The application does not have means of mutual identification and authentication. The delegated authorization rights would be restricted to a minimum level of permissions (scopes). The lifespan of the delegated authorization rights (in terms of access and refresh tokens) will be minimal or for one time use only. (b) *Trust Assurance Level 1*. The applications have the means of establishing mutual identification and authentication. The delegated authorization rights (scopes) will be more permissive in nature. The lifespan of the authorization rights (in terms of access and refresh tokens) will be of a more persistent nature. *How Does this help?* 3. We are moving from the less formal classification and interpretation of client applications to a more robust definition based on the principles of mutual identification and authentication. 4. It can additionally form the basis of DPoP. *Option II:* 5. In the main meeting we discussed the possibility of moving towards a uniform OAuth flow by converting public apps to confidential apps. We need more discussions on the same. Regards and Best Wishes Jaimandeep Singh
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
