Thanks Nov and Dave! I have several questions about CIBA. Is this mailing list the appropriate place to ask them or is there another mailing list that is for discussions about CIBA?
Daniel Roesler dan...@utilityapi.com On Tue, Jan 15, 2019 at 11:01 PM Dave Tonge <dave.to...@momentumft.co.uk> wrote: > > Hi Daniel > > This is an interesting use-case. As mentioned by nov, CIBA could potentially > solve this problem. > The difference would be step 9 in your user story. Instead of the user > entering the code at the kiosk, they would click on a link in the email (or > reply the text) to confirm that they grant access. This wouldn't require > building a costly user interface, but rather the utilities would need to > provide a single end-user facing route to deal with confirmations via email. > > From a user experience perspective, it would be nicer as the user wouldn't > have to enter any codes. They would simply enter their address (or some other > identifier) at the kiosk, wait for an email or text, click the email or reply > the text, and access would be granted. > > It is also flexible to support utilities that wanted to gain a higher lever > of assurance. Such utilities could ask the user for additional knowledge > factors without changing the flow. > > Dave > > > > > On Wed, 16 Jan 2019 at 04:02, nov matake <mat...@gmail.com> wrote: >> >> Your use case seems fit CIBA which is being defined in OpenID Foundation. >> >> The section6 of CIBA spec will describe how your use case fit it. >> https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.6 >> >> CIBA is an extension of OpenID Connect, not OAuth, but since OpenID Connect >> itself is an extension of OAuth2, you should be able to use it in OAuth >> context too. >> >> Cheers, >> >> nov >> >> 2019年1月16日(水) 10:25 Daniel Roesler <daniel=40utilityapi....@dmarc.ietf.org>: >>> >>> 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 >> >> >> >> -- >> nov matake >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Dave Tonge > CTO > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct Authority > ("FCA"). Moneyhub Financial Technology is entered on the Financial Services > Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology > is registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2018 © > > DISCLAIMER: This email (including any attachments) is subject to copyright, > and the information in it is confidential. Use of this email or of any > information in it other than by the addressee is unauthorised and unlawful. > Whilst reasonable efforts are made to ensure that any attachments are > virus-free, it is the recipient's sole responsibility to scan all attachments > for viruses. All calls and emails to and from this company may be monitored > and recorded for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those of the > author and do not necessarily represent the opinions of Moneyhub Financial > Technology Limited or of any other group company. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
