Subject: [OAUTH-WG] OTP-flow use case (sharing energy data)

From: Daniel Roesler <[email-masked]>
Date: Tue, 15 Jan 2019 09:51:07 -0600

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-masked]

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 15 Jan 2019 22:04:35 +0100

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-masked]> wrote:

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

---

From: Omer Levi Hevroni <[email-masked]>
Date: Tue, 15 Jan 2019 23:13:11 +0200

Nope, device flow still requires interactive login flow from the user, just
on another device. My flow aims for strong device authentication, without
any user interaction. My flow has some similarity to oauth client assertion
flow - https://tools.ietf.org/html/rfc7523, with modifications for
mobile/IoT devices.

On Tue, Jan 15, 2019 at 11:05 PM Samuel Erdtman <[email-masked]> wrote:

>> 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).
>>
>> 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
>> 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.
>>
>> 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

---

From: Daniel Roesler <[email-masked]>
Date: Tue, 15 Jan 2019 19:24:09 -0600

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
[email-masked]

On Tue, Jan 15, 2019 at 3:04 PM Samuel Erdtman <[email-masked]> wrote:
> 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.
>
> On Tue, Jan 15, 2019 at 4:54 PM Daniel Roesler <daniel=[email-masked]> 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).
>>
>> 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.
>>
>> 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-masked]
>>

---

From: nov matake <[email-masked]>
Date: Wed, 16 Jan 2019 12:01:30 +0900

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=[email-masked]>:

> > 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.
> >
> >> 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
> >> 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).
> >>
> >> 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-masked]
> >>

-- 
nov matake

---

From: Dave Tonge <[email-masked]>
Date: Wed, 16 Jan 2019 06:01:14 +0100

Hi Daniel

This is an interesting use-case. As mentioned by nov, CIBA
<https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>
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 <[email-masked]> wrote:

> 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=[email-masked]
> <[email-masked]..org>>:
>
>> Thanks for the reply!
>>
>> >> 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

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
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.

---

From: Daniel Roesler <[email-masked]>
Date: Wed, 16 Jan 2019 08:35:19 -0600

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
[email-masked]

On Tue, Jan 15, 2019 at 11:01 PM Dave Tonge <[email-masked]> 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
>
>
>
>
>> 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
>>
> 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 .
> 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.

---

From: Dave Tonge <[email-masked]>
Date: Wed, 16 Jan 2019 15:50:57 +0100

Hi Daniel

This is the repo: https://bitbucket.org/openid/mobile/src and it has an
issue tracker.
This is the mailing list:
http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

It would be good to get your feedback.

Thanks

Dave

On Wed, 16 Jan 2019 at 15:35, Daniel Roesler <[email-masked]> wrote:

> 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
> >
> >
> >
> >
> >>> > 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.
> >>> >
> >>> >> 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).
> >>> >>
> >>> >> 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
> >>> >> 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-masked]
> >>> >>
> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub
> Financial Technology is registered in England & Wales, company registration
> number  06909772 .
> > 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