Thanks Torsten.
As another meta comment, in general I am not disagreeing with the guidance-
I just think that the language we use should make it easier for
practitioners to understand what they are supposed to do to put this
guidance in concrete terms. That includes better clarifying risks, opening
> How would the token endpoint detect login status of the user?
Oddball idea: why not use the cookie? If the assumption is that the RT is being
used from a client-side browser-based app, and CORS allows for credentials,
then perhaps this is a way to bind the RT to the user's browser session. The
Not pure OAuth. This only came up as a question while I was implementing code
flow/pkce for oidc-client-js.
I can appreciate not expanding the current OAuth2 behavior in the BCP, so
that's fair. I only wanted to mention it in case it had not been considered.
Having said that, I think I will imp
Thanks again everyone for the additional feedback on -01. I've incorporated
the discussion into a new draft which is now published.
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02
Here's a summary of the changes:
* Added a new section with recommendations for refresh tokens
> Am 08.12.2018 um 16:55 schrieb Nov Matake :
>
> But even using code flow, issuing TB-bound access token has same difficulty,
> doesn't it?
> I don’t think this issue is relate to implicit flow.
Determining the referred token binding id and proving ownership of the key
isn’t easy. Brian is t
Do you know of anyone currently doing this today in an OAuth-only
application?
If the group wanted to take some existing OIDC mechanisms and apply them to
OAuth, I feel like that needs to happen in a separate RFC, and that's a
much bigger discussion. This BCP shouldn't really be defining new behav
For the same reason the implicit flow uses it -- to reduce exposure of the
response params. I know the code is protected with the code_verifier, but it
wouldn't hurt to reduce its exposure, no?
-Brock
On 12/8/2018 1:23:41 PM, Aaron Parecki wrote:
What would be the benefit of using this respons
What would be the benefit of using this response type? Are you aware of any
OAuth (not OIDC) clients that do this today?
- Aaron
On Sat, Dec 8, 2018 at 7:29 AM Brock Allen wrote:
> Should the BCP suggest using OIDC's response_type=fragment as the
> mechanism for returning the code from the AS?
> Is this a matter of saying they should have an API for these clients
which exposes less of the risky activities? That cookies provide a
defense against XSS exfiltration? And/or other?
HTTPOnly cookies prevent exfiltration of session or token data stored in
cookies. Those cookies can be REPLAYED
Hi Torsten,
> On Dec 8, 2018, at 22:20, Torsten Lodderstedt wrote:
>
> Hi Nov,
>
>> Am 08.12.2018 um 00:20 schrieb Nov Matake :
>>
>> For me, it seems very hard to issue TB-bound token for JS app and
>> MTLS-bound token for its backend server at same time.
>
> Issuing TB tokens in case of i
Should the BCP suggest using OIDC's response_type=fragment as the mechanism for
returning the code from the AS? Or simply suggest using the fragment component
of the redirect_uri for the code, without a response_type parameter (IOW don't
allow it to be dynamic)?
-Brock
Hi Nov,
> Am 08.12.2018 um 00:20 schrieb Nov Matake :
>
> For me, it seems very hard to issue TB-bound token for JS app and MTLS-bound
> token for its backend server at same time.
Issuing TB tokens in case of implicit is anyway hard. You need to issue a HTTP
redirect to the RS and the RS must
Hi Vittorio,
> Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci :
>
> Thank you Torsten.
> I think that a lot of the considerations below need to be tempered with
> concrete considerations about the features developers can actually rely on
> today.
> I agree with identifying the theoretical fra
13 matches
Mail list logo
