Howdy, Rifaat recommended I post to the mailing list. Specifically, I am looking for a mentor and feedback on a potential new OAuth flow (currently called OTP-flow).
Background: I am a participant in the California Public Utility Commission's Customer Data Access Committee (CPUC CDAC), and we are working on improving utility data access to accelerate deployment of more renewable and energy efficiency technologies to fight climate change. However, we are currently struggling with a use-case for which we can't seem to find a good OAuth flow. Use-case: Utility customers want to share their utility data (e.g. historical energy usage) with a client (e.g. an energy auditor, to perform some energy efficiency analysis). However, there are two problems that often occur: 1) Most utility customers do not have online accounts or forgot their login information. This makes typical OAuth user interface complex, since you have to either create an online account in the flow or do some sort of multi-step password-reset/verification process. 2) Utilities are not strongly incentivized to optimize complex UI/UX for the customer in the authorization server interface. In the committee we've gotten to the point where we have to specify number of clicks, div height requirements, and minimum pageload times for a utility to implement their OAuth flows (and then utilities want to charge rate payers for the cost of each UI/UX improvement). So, we have been brainstorming possible ways around these problems, and we think it may require a new type of authorization flow using one-time passcodes (OTP) instead of redirecting the user to the utility for normal OAuth. Luckily, even though utility customers may not have an online account at the utility, the utility usually still has (a) a way of uniquely identifying them and (b) a way of contacting them (phone, email, etc.). I'd like to see if the OAuth working group is an appropriate place to help develop this flow (or if there has already been work done such a flow). I'm happy to write the initial draft, but I would very much appreciate some mentorship from someone more experienced in the workgroup. OTP-flow diagram and example: https://pastebin.com/raw/4Gx8LAQ1 The OTP-flow (called Solution 1b in the committee) is a mix of OAuth device-flow and authorization code flow. Since we want to avoid asking utilities to implement complex authorization interfaces (problem #2 above), the client asks the utility to send the user_code directly to the user (via text/phone/email), then the client asks the user for the user_code and submits it to the utility to get an access token. Also, there is an initial step of identifying (but not authenticating) the user and determining the way in which the OTP code should be sent. If utilities are given some sort of non-secret user identification (e.g. address, phone number, account number, etc.), they should be able to send a user_code to the user that the user can give to the client for authorization. Hopefully, this can shift most of the complex UI/UX development cost away from the utility and onto the third party clients. Unfortunately, the energy industry can be quite behind on the latest and greatest OAuth developments, but we're trying to get better :) Thanks very much, Daniel Roesler dan...@utilityapi.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
