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

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 kio

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

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

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

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 f

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

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 brows

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

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 f

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

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

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

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 som

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

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

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

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

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

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 fol

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

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

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

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

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

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_a