+1
On Thu, 29 Nov 2018 at 19:06, Torsten Lodderstedt
wrote:
> Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the
> text. That’s our proposal:
>
> —
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other
Sure. But given that TLS token binding is often put forth as a mitigation
against token theft and replay, it's worth noting that on its own it does not
address this risk when the replay is coming from the same browser, and the RS
needs to support CORS.
--
Annabelle Richard Backman
AWS Identity
> Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some
> identity guarantees…
Yes, provided that the AS can verify that the claimed URI is a valid URI for
the identity being asserted by the client. And this identity guarantee would
apply to an public native app client jus
Big +1 here. I'd be in favor of the document discussing the potential
benefits of tying the refresh token to a session in some situations but
very much agree that the spectrum of desired behaviors is much too wide to
normatively recommend any particular option.
On Wed, Nov 28, 2018 at 11:19 PM Nei
+1
Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
PLEASE READ :This e-mail is confidential and intended for the named recipient
only.
If you are not an intended recipient, p
+1
On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt Hi all,
>
> based on your feedback on the list and off list, Daniel and I polished the
> text. That’s our proposal:
>
> —
> In order to avoid these issues, clients MUST NOT use the implicit
> grant (response type "token") or any other response
Hi all,
based on your feedback on the list and off list, Daniel and I polished the
text. That’s our proposal:
—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access
tokens in the authorization response, such a
In the case of dynamic client registration for apps, I suppose the
implementations will use other techniques (many of them are proprietary) to
test if the app is the one created by themselves or not. Otherwise, it would
not improve the situation very much.
Nat
Nat Sakimura / n-sakim...@nri.co.
Hi all,
It’s worth adding that a per-instance dynamic registration of a native client
can still imply a higher level of trust than a public client and registration
isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines
an “initial access token”:
> OAuth 2.0 access token
I am ok with that.
On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow
> „token“ to be used if the token would sender constrained. This comple
Hi,
thanks for pointing this out!
This was exactly what confused us during reading *-* the main threat we
see and which is not addressed is related to the app impersonation attack.
Even PKCE does not help against the app impersonation attack.
So a "Native App + Dynamic Client Registration" can be
Hi all,
I support this proposal of recommending authorization code grant and advising
to not use implicit grant.
As a developer we value clean and robust specifications with less opportunity
for mistakes.
Thank you,
Petteri Stenius / Ubisecure
-Original Message-
From: OAuth On Behalf
12 matches
Mail list logo
