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= [email protected]> 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 > [email protected] > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
