Thanks for the reply! Yes, that is essentially what we would like to do. We really like the "here's a code to authorize" part of device-flow, but we are trying to not require the authorization server build a user interface for the user to authenticate themselves and enter the code (because we've found it is very costly for utilities to build these interfaces). We'd much rather the user get a code directly that they can input into the client for authorization, hence reversing steps C & D in device-flow (and the client now is responsible for developing the costly user interface).
However, in order to reverse C & D, steps A & B needs to provide some sort of user identifier and delivery method (so that the authorization server knows to who this authorization request is directed and how to send the user_code). In order to figure that out, we added a identification and delivery negotiation step in front of step A & B that lets the client and authorization server negotiate those things before kicking off the OTP code sending (e.g. reverse steps C & D). I'm not really sure how we'd go about building off of device-flow if we're reversing much of the process, changing what data is sent in each step, and adding a step at the start. OTP-flow is less of a "device" focused authorization and more of an on-the-go focused authorization. Our main example we sanity check this for is the "Hardware Store Kiosk" story: 1. Heather Homeowner walks into a hardware store. 2. There's a kiosk by the lighting section offering free energy audits. 3. It says it needs to pull her energy usage data to perform the energy audit. 4. She doesn't remember (or have) her utility login, so she enters her address instead. 6. She is asked if she'd like to receive a text or email with a verification code. 7. She selects she wants to receive a text. 8. She receives a text with a code and message about the scope of the authorization. 9. She enters the code on the kiosk. 10. The kiosk pulls her energy usage data and generates an energy audit. This story allows users who only know their address or some other basic identifier (phone number, email, etc.) to be able to get instant energy audits for lighting upgrades, solar quotes, energy star appliances, EV charging costs, etc. Unfortunately, most people only think about their energy use when they are out and about and encounter energy products (e.g. in a hardware store), so we're trying to make it easy for them to get an energy audit with minimal information input or device requirements. Thanks again, Daniel Roesler dan...@utilityapi.com On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman <sam...@erdtman.se> wrote: > > To me this looks similar to the device flow. > > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13 > > See figure 1, my interpretation of what you want to do is to split up step B > so that the code goes via another channel and then revers the direction of C > and D. > > So maybe you could ride on some of the work done in the device flow draft. > > > > > > On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler > <daniel=40utilityapi....@dmarc.ietf.org> wrote: >> >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
