Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Dave Tonge]

I'm in favour of the `mtls_endpoints` metadata parameter - although it
should be optional.
While a 307 redirect seems kind of elegant I worry, like you,  that not all
clients would handle it appropriately.
There would probably need to be an error defined for clients who attempt to
use `tls_client_auth` at the regular endpoint.

Dave

On Mon, 14 Jan 2019 at 22:29, Brian Campbell  wrote:

> Trying to summarize things somewhat here and focus in hopefully towards
> some decision. There's basically an idea on the table to add an AS metadata
> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
> which contains endpoints that a client doing MTLS would use rather than the
> regular endpoints. A straw-man example might look like this (with
> mtls_endpoints being that new parameter).
>
> {
>   "issuer":"https://server.example.com";,
>   "authorization_endpoint":"https://server.example.com/authz";,
>   "token_endpoint":"https://server.example.com/token";,
>   "token_endpoint_auth_methods_supported":[
> "client_secret_basic","tls_client_auth", "none"],
>   "userinfo_endpoint":"https://server.example.com/userinfo";,
>   "revocation_endpoint":"https://server.example.com/revo";,
>   "jwks_uri":"https://server.example.com/jwks.json";,
>
>
>
>
> *  "mtls_endpoints":{
> "token_endpoint":"https://mtls.example.com/token
> ","userinfo_endpoint":"https://mtls
> .example.com/userinfo
> ","revocation_endpoint":"https://mtls
> .example.com/revo
> "  }*
> }
>
> The idea behind this is that "regular" clients (those not doing MTLS) will
> use the regular endpoints. And only the host/port of the endpoints listed
> in mtls_endpoints will be set up to request TLS client certificates during
> handshake. Thus any potential impact of the CertificateRequest message
> being sent in the TLS handshake can be avoided for all the other regular
> clients that are not going to do MTLS - including and most importantly
> in-browser javascript clients where there can be less than desirable UI
> presented to the end-user.
>
> The arguments in favor of that seem to be basically that it allows for AS
> deployments to support MTLS while still allowing for a "not broken" UX for
> end-users of clients (in-browser javascript clients) that aren't doing
> MTLS. And that it's not much in terms of adding to the spec and complexity
> of implementations.
>
> The arguments against it seem to be 1) the bad UX isn't really that bad
> and/or will only happen to a subset of users 2) there are other things that
> can be done, such as 307ing or renegotiation/post-handshake client auth, to
> avoid the bad UX.
>
> Speaking for myself, I'm kinda torn on it.
>
> I will say that, in addition to the folks that have pointed out that
> renegotiation just isn't possible in some cases, my experience trying to do
> something like that in the past was not particularly successful or
> encouraging. That could have been my fault, of course, but still seems a
> relevant data point. I also have my doubts about the actual difficulty of
> getting an AS to issue a 307 like response for requests based on the
> calling client and the likelihood that some/all OAuth client software would
> handle it appropriately.
>
>
> On Fri, Jan 11, 2019 at 12:32 PM David Waite 
> wrote:
>
>>
>>
>> > On Jan 11, 2019, at 3:32 AM, Neil Madden 
>> wrote:
>> >
>> > On 9 Jan 2019, at 05:54, David Waite 
>> wrote:
>> >>
>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> >>>
>> >> 
>> >>
>> >>> All of that is meant as an explanation of sorts to say that I think
>> that things are actually okay enough as is and that I'd like to retract the
>> proposal I'd previously made about the MTLS draft introducing a new AS
>> metadata parameter. It is admittedly interesting (ironic?) that Neil sent a
>> message in support of the proposal as I was writing this. It did give me
>> pause but ultimately didn't change my opinion that it's not worth it to add
>> this new AS metadata parameter.
>> >>
>> >> Note that the AS could make a decision based on the token endpoint
>> request - such as a policy associated with the “client_id”, or via a
>> parameter in the ilk of “client_assertion_type” indicating MTLS was desired
>> by this public client installation. The AS could then to TLS 1.2
>> renegotiation, 1.3 post-handshake client authentication, or even use 307
>> temporary redirects to another token endpoint to perform mutual
>> authentication.
>> >
>> > Renegotiation is an intriguing option, but it has some practical
>> difficulties. Our AS product runs in a Java servlet container, where it is
>> pretty much impossible to dynamically trigger renegotiation without
>> accessing private internal APIs of the container. I also don’t know how you
>> could coordinate this in the common scenario where TLS is termin

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

I'm in favour of both 307 and metadata.

   - case 307 - I don't recall ever encountering an http client software
   that wouldn't have an option for following redirects, same for a server
   side frameworks not having the option to do a 307 response with a location
   header.
   - case 307 - Relying purely on a new metadata doesn't help in the
   scenario David put forth earlier about clients not being aware of using
   mtls, a device policy of sorts.
   - case metadata - no second request if the client knows there's an mtls
   endpoint it should use.

Maybe we should specify both as optional for an AS to deploy and a client
to be ready for?

S pozdravem,
*Filip Skokan*


On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge 
wrote:

> I'm in favour of the `mtls_endpoints` metadata parameter - although it
> should be optional.
> While a 307 redirect seems kind of elegant I worry, like you,  that not
> all clients would handle it appropriately.
> There would probably need to be an error defined for clients who attempt
> to use `tls_client_auth` at the regular endpoint.
>
> Dave
>
> On Mon, 14 Jan 2019 at 22:29, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Trying to summarize things somewhat here and focus in hopefully towards
>> some decision. There's basically an idea on the table to add an AS metadata
>> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
>> which contains endpoints that a client doing MTLS would use rather than the
>> regular endpoints. A straw-man example might look like this (with
>> mtls_endpoints being that new parameter).
>>
>> {
>>   "issuer":"https://server.example.com";,
>>   "authorization_endpoint":"https://server.example.com/authz";,
>>   "token_endpoint":"https://server.example.com/token";,
>>   "token_endpoint_auth_methods_supported":[
>> "client_secret_basic","tls_client_auth", "none"],
>>   "userinfo_endpoint":"https://server.example.com/userinfo";,
>>   "revocation_endpoint":"https://server.example.com/revo";,
>>   "jwks_uri":"https://server.example.com/jwks.json";,
>>
>>
>>
>>
>> *  "mtls_endpoints":{
>> "token_endpoint":"https://mtls.example.com/token
>> ","userinfo_endpoint":"https://mtls
>> .example.com/userinfo
>> ","revocation_endpoint":"https://mtls
>> ..example.com/revo
>> "  }*
>> }
>>
>> The idea behind this is that "regular" clients (those not doing MTLS)
>> will use the regular endpoints. And only the host/port of the endpoints
>> listed in mtls_endpoints will be set up to request TLS client certificates
>> during handshake.. Thus any potential impact of the CertificateRequest
>> message being sent in the TLS handshake can be avoided for all the other
>> regular clients that are not going to do MTLS - including and most
>> importantly in-browser javascript clients where there can be less than
>> desirable UI presented to the end-user.
>>
>> The arguments in favor of that seem to be basically that it allows for AS
>> deployments to support MTLS while still allowing for a "not broken" UX for
>> end-users of clients (in-browser javascript clients) that aren't doing
>> MTLS. And that it's not much in terms of adding to the spec and complexity
>> of implementations.
>>
>> The arguments against it seem to be 1) the bad UX isn't really that bad
>> and/or will only happen to a subset of users 2) there are other things that
>> can be done, such as 307ing or renegotiation/post-handshake client auth, to
>> avoid the bad UX.
>>
>> Speaking for myself, I'm kinda torn on it.
>>
>> I will say that, in addition to the folks that have pointed out that
>> renegotiation just isn't possible in some cases, my experience trying to do
>> something like that in the past was not particularly successful or
>> encouraging. That could have been my fault, of course, but still seems a
>> relevant data point. I also have my doubts about the actual difficulty of
>> getting an AS to issue a 307 like response for requests based on the
>> calling client and the likelihood that some/all OAuth client software would
>> handle it appropriately.
>>
>>
>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <
>> da...@alkaline-solutions.com> wrote:
>>
>>>
>>>
>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden 
>>> wrote:
>>> >
>>> > On 9 Jan 2019, at 05:54, David Waite 
>>> wrote:
>>> >>
>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >> 40pingidentity@dmarc.ietf.org> wrote:
>>> >>>
>>> >> 
>>> >>
>>> >>> All of that is meant as an explanation of sorts to say that I think
>>> that things are actually okay enough as is and that I'd like to retract the
>>> proposal I'd previously made about the MTLS draft introducing a new AS
>>> metadata parameter. It is admittedly interesting (ironic?) that Neil sent a
>>> message in support of the proposal as I was writing this. It did give me
>>> pause but ultimately didn't change m

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

It would definitely be optional, apologies if that wasn't made clear. It'd
be something to the effect of optional for the AS to include and clients
doing MTLS would use it when present in AS metadata.

On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge 
wrote:

> I'm in favour of the `mtls_endpoints` metadata parameter - although it
> should be optional.
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

I don't know that the use of 307 would need to be discussed in the document
itself.

On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan  wrote:

> I'm in favour of both 307 and metadata.
>
>- case 307 - I don't recall ever encountering an http client software
>that wouldn't have an option for following redirects, same for a server
>side frameworks not having the option to do a 307 response with a location
>header.
>- case 307 - Relying purely on a new metadata doesn't help in the
>scenario David put forth earlier about clients not being aware of using
>mtls, a device policy of sorts.
>- case metadata - no second request if the client knows there's an
>mtls endpoint it should use.
>
> Maybe we should specify both as optional for an AS to deploy and a client
> to be ready for?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge 
> wrote:
>
>> I'm in favour of the `mtls_endpoints` metadata parameter - although it
>> should be optional.
>> While a 307 redirect seems kind of elegant I worry, like you,  that not
>> all clients would handle it appropriately.
>> There would probably need to be an error defined for clients who attempt
>> to use `tls_client_auth` at the regular endpoint.
>>
>> Dave
>>
>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> Trying to summarize things somewhat here and focus in hopefully towards
>>> some decision. There's basically an idea on the table to add an AS metadata
>>> parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
>>> which contains endpoints that a client doing MTLS would use rather than the
>>> regular endpoints. A straw-man example might look like this (with
>>> mtls_endpoints being that new parameter).
>>>
>>> {
>>>   "issuer":"https://server.example.com";,
>>>   "authorization_endpoint":"https://server.example.com/authz";,
>>>   "token_endpoint":"https://server.example.com/token";,
>>>   "token_endpoint_auth_methods_supported":[
>>> "client_secret_basic","tls_client_auth", "none"],
>>>   "userinfo_endpoint":"https://server..example.com/userinfo
>>> ",
>>>   "revocation_endpoint":"https://server.example.com/revo";,
>>>   "jwks_uri":"https://server.example.com/jwks.json";,
>>>
>>>
>>>
>>>
>>> *  "mtls_endpoints":{
>>> "token_endpoint":"https://mtls.example.com/token
>>> ","userinfo_endpoint":"https://mtls
>>> .example.com/userinfo
>>> ","revocation_endpoint":"https://mtls
>>> ..example.com/revo
>>> "  }*
>>> }
>>>
>>> The idea behind this is that "regular" clients (those not doing MTLS)
>>> will use the regular endpoints. And only the host/port of the endpoints
>>> listed in mtls_endpoints will be set up to request TLS client certificates
>>> during handshake.. Thus any potential impact of the CertificateRequest
>>> message being sent in the TLS handshake can be avoided for all the other
>>> regular clients that are not going to do MTLS - including and most
>>> importantly in-browser javascript clients where there can be less than
>>> desirable UI presented to the end-user.
>>>
>>> The arguments in favor of that seem to be basically that it allows for
>>> AS deployments to support MTLS while still allowing for a "not broken" UX
>>> for end-users of clients (in-browser javascript clients) that aren't doing
>>> MTLS. And that it's not much in terms of adding to the spec and complexity
>>> of implementations.
>>>
>>> The arguments against it seem to be 1) the bad UX isn't really that bad
>>> and/or will only happen to a subset of users 2) there are other things that
>>> can be done, such as 307ing or renegotiation/post-handshake client auth, to
>>> avoid the bad UX.
>>>
>>> Speaking for myself, I'm kinda torn on it.
>>>
>>> I will say that, in addition to the folks that have pointed out that
>>> renegotiation just isn't possible in some cases, my experience trying to do
>>> something like that in the past was not particularly successful or
>>> encouraging. That could have been my fault, of course, but still seems a
>>> relevant data point. I also have my doubts about the actual difficulty of
>>> getting an AS to issue a 307 like response for requests based on the
>>> calling client and the likelihood that some/all OAuth client software would
>>> handle it appropriately.
>>>
>>>
>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <
>>> da...@alkaline-solutions.com> wrote:
>>>


 > On Jan 11, 2019, at 3:32 AM, Neil Madden 
 wrote:
 >
 > On 9 Jan 2019, at 05:54, David Waite 
 wrote:
 >>
 >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell >>> 40pingidentity@dmarc.ietf.org> wrote:
 >>>
 >> 
 >>
 >>> All of that is meant as an explanation of sorts to say that I think
 that things are actually okay enough a

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

>
> I don't know that the use of 307 would need to be discussed in the
> document itself.


If the clients are supposed to be ready for this, yeah. For instance, my
client software by default doesn't follow redirects, in order for it to be
ready for mtls client authentication i'd have to know 307 is a possibility
and whitelist 307 as a valid code to be followed.

S pozdravem,
*Filip Skokan*


On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell 
wrote:

> I don't know that the use of 307 would need to be discussed in the
> document itself.
>
> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan  wrote:
>
>> I'm in favour of both 307 and metadata.
>>
>>- case 307 - I don't recall ever encountering an http client software
>>that wouldn't have an option for following redirects, same for a server
>>side frameworks not having the option to do a 307 response with a location
>>header.
>>- case 307 - Relying purely on a new metadata doesn't help in the
>>scenario David put forth earlier about clients not being aware of using
>>mtls, a device policy of sorts.
>>- case metadata - no second request if the client knows there's an
>>mtls endpoint it should use.
>>
>> Maybe we should specify both as optional for an AS to deploy and a client
>> to be ready for?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge 
>> wrote:
>>
>>> I'm in favour of the `mtls_endpoints` metadata parameter - although it
>>> should be optional.
>>> While a 307 redirect seems kind of elegant I worry, like you,  that not
>>> all clients would handle it appropriately.
>>> There would probably need to be an error defined for clients who attempt
>>> to use `tls_client_auth` at the regular endpoint.
>>>
>>> Dave
>>>
>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell >> 40pingidentity@dmarc.ietf.org> wrote:
>>>
 Trying to summarize things somewhat here and focus in hopefully towards
 some decision. There's basically an idea on the table to add an AS metadata
 parameter to the draft-ietf-oauth-mtls doc that would be a JSON object
 which contains endpoints that a client doing MTLS would use rather than the
 regular endpoints. A straw-man example might look like this (with
 mtls_endpoints being that new parameter).

 {
   "issuer":"https://server.example.com";,
   "authorization_endpoint":"https://server.example.com/authz";,
   "token_endpoint":"https://server.example.com/token";,
   "token_endpoint_auth_methods_supported":[
 "client_secret_basic","tls_client_auth", "none"],
   "userinfo_endpoint":"https://server..example.com/userinfo
 ",
   "revocation_endpoint":"https://server.example.com/revo";,
   "jwks_uri":"https://server.example.com/jwks.json";,




 *  "mtls_endpoints":{
 "token_endpoint":"https://mtls.example.com/token
 ","userinfo_endpoint":"https://mtls
 .example.com/userinfo
 ","revocation_endpoint":"https://mtls
 ..example.com/revo
 "  }*
 }

 The idea behind this is that "regular" clients (those not doing MTLS)
 will use the regular endpoints. And only the host/port of the endpoints
 listed in mtls_endpoints will be set up to request TLS client certificates
 during handshake.. Thus any potential impact of the CertificateRequest
 message being sent in the TLS handshake can be avoided for all the other
 regular clients that are not going to do MTLS - including and most
 importantly in-browser javascript clients where there can be less than
 desirable UI presented to the end-user.

 The arguments in favor of that seem to be basically that it allows for
 AS deployments to support MTLS while still allowing for a "not broken" UX
 for end-users of clients (in-browser javascript clients) that aren't doing
 MTLS. And that it's not much in terms of adding to the spec and complexity
 of implementations.

 The arguments against it seem to be 1) the bad UX isn't really that bad
 and/or will only happen to a subset of users 2) there are other things that
 can be done, such as 307ing or renegotiation/post-handshake client auth, to
 avoid the bad UX.

 Speaking for myself, I'm kinda torn on it.

 I will say that, in addition to the folks that have pointed out that
 renegotiation just isn't possible in some cases, my experience trying to do
 something like that in the past was not particularly successful or
 encouraging. That could have been my fault, of course, but still seems a
 relevant data point. I also have my doubts about the actual difficulty of
 getting an AS to issue a 307 like response for requests based on the
 calling client and the likelihood that some/

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

[Daniel Roesler]

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

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

[Samuel Erdtman]

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

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

[Omer Levi Hevroni]

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  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  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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT)

[William Denniss]

On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-device-flow-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for addressing my Discuss points.  I would still prefer to see a
> normative requirement for explicit user approval (as opposed to  just the
> descriptive statement that the chance to approve/deny should be offered),
> but I can understand the sentiment that such a requirement  on  the UI is
> not a matter for interoperability and could not be reliably enforced
> anyway.
>

Thank you again for your review.

The UI requirements not being a matter for interoperability is indeed why
there is no normative text for that, and we're following the approach taken
by other IETF OAuth specifications which also leave this up to the
implementors. I understand your concerns here, but I hope that the current
non-normative guidance is enough.



>
> Original COMMENT  section preserved below.
>
> Please use the RFC 8174 boilerplate instead of the RFC 2119 one.
>
> Section 3.2
>
> The example expires in 30 minutes?  That seems longer than needed; wouldn't
> 5 minutes do?
>
> Section 3.3
>
> I agree with directorate reviewer that the MUST NOT requirement for
> displaying the device_code should justify that requirement by discussing
> the consequences of exposure.
>
> Section 3.5
>
>authorization_pending
>   The authorization request is still pending as the end-user hasn't
>   yet completed the user interaction steps (Section 3.3).  The
>   client should repeat the Access Token Request to the token
>   endpoint.
>
> I feel like we want to mention the 'interval' here or some other discussion
> of an inter-request delay.
>
> Also, please clarify "reasonable default polling interval", per multiple
> directorate reviews.
>
> Section 5.2
>
> Please clarify the entities involved in "the backchannel flow" that can be
> MITM'd.
>
> Section 5.6
>
> The "short-range" part of a "short-range wireless signal" partially depends
> on how big the receiver's antenna is.  So perhaps we should be careful
> about indicating that this has more security value than it does.
>
> Section 6.1
>
> I'm not sure I understand the usage of "case-insensitive", here -- how
> would the user have an expectation of case-insensitivity?  Perhaps it is
> better to just say "majuscule" or "upper case" or whatever.
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] comment on security topics-11 - refresh authentication

[Phil Hunt]

I have had a couple reviewers comment whether this means client authentication 
is optional in Sec 3.12 for token refresh:

>*  authentication of this client_id during token refresh, if
>   possible, and

Do we not mean authentication of the client or some equivalent (e.g. looking at 
browser cookies).

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com phil.h...@oracle.com 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Daniel Roesler]

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

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

[nov matake]

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 :

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

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

[Dave Tonge]

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  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  <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  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 > 40utilityapi@dmarc.ietf.org> wrote:
>> >>
>> >> Howdy,
>> >>
>> >> Rifaat recommended I post to the mailing l