, there is no reason to signal
back to the client nor convey this to the RS.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Sun, Dec 12, 2021 at 2:29 AM Benjamin Kaduk wrote:
>
>
> On Thu, Dec 09, 2021 at 0
The section from the RFC, allows for the *scope* or any other standard
parameter to be returned in the WWW-Authenticate header, those would be
machine readable.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress
either offers value nor should be reasonably
used for any purpose. If so desired, then let's put the mTLS signaling flag
as a claim where anyone and everyone can see it without having to magically
know what protocol was used to convey the HTTP message to the RS.
Warren Parad
Founder, CTO
Secure your us
This is a great answer.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Thu, Dec 9, 2021 at 2:52 PM Neil Madden
wrote:
> I don’t mind about a new error code, although I think it’s of limited
> v
Could you share a bit about the security implications that precipitates
needing to change the token type. I.e. what's the attack vector that is
closed by adding this?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress
to happen for confidential ones, must it also happen for
public clients? If we could prove that there exists a solution for public
clients or a lack of a need, then disallowing multi-use auth codes resolves
the exfiltration attack.
Warren Parad
Founder, CTO
Secure your user data with IAM
I think the allowed keys would have to be pre-registered in the AS.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Fri, Dec 3, 2021 at 5:01 PM Warren Parad wrote:
> While I agree this is a proble
the code exchange. Well this is
actually weird in the case of non-public clients, because it doesn't make
sense from that client perspective, as the "front-end" would need to now
have the constructed dpop_jkt even though it doesn't have the dpop key.
Warren Parad
Founder, CTO
Secure your
y provide an auth RFC recommending
better alternatives than sending a symmetric client_secret back to the AS.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman w
Or am I missing something that would actually make this a
non-negligible attack vector?
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman wrote:
by usage
location, not by parameter name and then this wouldn't be an issue. But
that's not up for discussion, right?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Nov 29, 2021 at 10:21 PM Fra
Would making it even simpler also work? (and is more consistent with the
6749 language)
>
> The decision of whether to accept such responses is beyond the scope of
> this specification.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
-/issues/216259#note_708055501>.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
code MUST be short-lived and at least
>> SHOULD, better MUST be one-time use.
>>
>> And ideally, the code SHOULD also be invalidated if the PKCE verifier
>> does not match, not sure if that is in the current text or not.
>>
>> -Daniel
>>
>>
>>
there is no evidence that
the original token generation was compromised. If it was, then the attacker
should have the access token (and potentially refresh token) which is far
worse.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authres
I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD
on an expected lifetime of an authorization code. I think sending the
message that these should be one time use except in exceptional
circumstances.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization
n for
me, while it is a valid argument, it isn't a sound one, due to its
implementation relying on Signatures and how Signatures is constructed at
this moment.
So rather than "this is PoP", let's focus on the problems needed to solve
for PoP Signatures to work.
Warren Parad
Foun
the RS know that there is supposed to be a signature, if the client
doesn't provide it?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle &
if it is credentialed? I would suggest instead of calling unknown
credentialed client as such, that we use *anonymous, unknown, or
unregistered*. And let the aspect of whether they are credentialed or not,
drive other behaviors.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service
The argument is "let's not have a requirement that doesn't serve to
increase security". If we can't think of a reason why it's necessary or
some attack it prevents against, it's better to allow AS to decide, rather
than forcing an unnecessary implementation detail.
Warren Parad
Fo
I feel like I'm missing something, what stops just plain old network
sniffing and replying the whole encrypted payload to the AS and getting
back a valid token?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress
is the reason I wanted to suggest
what are the non-negotiables for the authors of the new draft.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Oct 13, 2021 at 9:05 PM David Waite
wrote:
> Spe
ow
extensibility. Would your concerns be at least somewhat be mitigated by
allowing for solutions regarding (2) & (3)?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Oct 13, 2021 at 8:41 PM David W
the
roundtrip through libraries.)
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Oct 13, 2021 at 8:15 PM Jeff Craig wrote:
> OAuth 2.1 makes PKCE a requirement.
>
> I'm of two minds about PKCE for Confi
Thanks Aaron, that's a great point. In light of that, I would ask about the
recommendation for non-SPA. I was under the impression that non-SPA's don't
require the use of PKCE, which would make them vulnerable to replay
attacks. Or am I missing something?
Warren Parad
Founder, CTO
Secure your
se they are a special snowflake where SHOULD should apply".
Are we setting the standard or instead attempting to sustain a number of
"AS that are in compliance with the RFC"?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress &l
be interested in improving, for instance *cnf *being an array, and
attempting to utilize the Authorization header more effectively, but this
isn't the thread to discuss those. Is there a reason we can't just improve
the existing DPoP draft to remove the limitations you listed above?
Warren Parad
Founder
tial draft that
attempts to outline the problem and include a solution which supports a
majority of use cases, without being a very niche collaboration with the
existing signature draft.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https:
in this manner and expect a good outcome.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Fri, Oct 8, 2021 at 10:44 PM Richard Backman, Annabelle wrote:
> We need to come up with a better
a smaller window to where the signature is also
valid.*
That would allow us to better focus on the value that the RFC would
provide, rather than getting stuck with arbitrary implementation of another
RFC draft as it would apply to OAuth.
Warren Parad
Founder, CTO
Secure your user data with IAM a
this happening.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Oct 4, 2021 at 4:28 AM wrote:
> Thanks Dick,
>
>
>
> Our use case is basically the option 2. There is only one
This has been implemented in https://authress.io.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Sun, Sep 5, 2021 at 6:12 PM Takahiko Kawasaki wrote:
> Authlete supports the specification from vers
Ah in 5. Security Considerations
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Thu, Sep 2, 2021 at 10:25 AM Ash Narayanan
wrote:
> According to this specification, a client's request mus
Can you point out where it says that, I think I must of missed it.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan
wrote:
> Hey Warren,
>
> 7009 state
> that the token itself should be the only form of 'security' needed...as
> that's the point of OAuth.
>
> Regardless, 7009 needs to be made obsolete by a newer RFC.
>
> Ash
>
> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote:
>
>> What's the point in pas
What's the point in passing arbitrary other information that is already
known by the AS and does not provide the level of security necessary to
prevent abuse of the revocation endpoint?
On Thu, Sep 2, 2021, 01:12 Ash Narayanan wrote:
> Hi Thomas,
>
> The approach you've suggested sounds good.
ctly by the user, but it cannot be done by
amending the revocation endpoint.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Tue, Aug 24, 2021 at 9:44 AM Emond Papegaaij
wrote:
> On Mon, Aug 23, 2021
additional information would be appreciated.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Aug 9, 2021 at 10:44 PM Kevat Shah wrote:
> @wpa...@rhosys.ch - Using forgot password and reg
I think it would be prudent to potentially ask *why?* What problem is
necessary to be solved by discussing/standardizing these particular
features? There could be, but without understanding, knowing how best to
tackle it is a challenging conversation without the right context.
Warren Parad
Reviewed, no concerns.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Tue, Jun 8, 2021 at 2:48 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is to start a *WG Last Call *for the *Authorizatio
is a
sane place to put the urls. You'd have to justify that putting the
configuration into the input of the SDK is actually non-obvious. But I
haven't seen that discussion yet.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <ht
I can't follow the discussion. So I'm still missing why the endpoints would
need to be listed anywhere. Isn't the developer of the html page, the same
developer that will configure the HTTP request to go to the backend?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization
I agree, missing context for this:
As discussed in the interim, a well known set of endpoints (or even a
single root client discovery document) might not always be available for
control to the webpage depending on where and how it is hosted, on the
other hand the HTML it serves always, I hope,
Authress supports PAR.
- Warren
On Wed, Mar 24, 2021 at 8:54 PM Hannes Tschofenig
wrote:
> Hi all,
>
>
>
> I am working on the shepherd writeup and I need information about the
> implementation status of this specification.
>
>
>
> Can you share whether you are implementing, or planning to
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Thu, Mar 18, 2021 at 1:07 PM Neil Madden
wrote:
>
>
> On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef
> wrote:
>
> On Thu, Mar 18, 202
in the Desktop OS environment that could perpetrate this attack. However,
without thinking too much about it, I'm biased to believe existing TLS and
browser security mechanisms are sufficient with the addition of the
*issuer *included in the response.
Warren Parad
Founder, CTO
Secure your user data with IAM
I'm probably missing ten different important nuances here though.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Mar 3, 2021 at 10:15 PM Sam Goto
wrote:
> Unclear to me if this is a perfec
le, but I don't see what that has to do with our discussion.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Mar 1, 2021 at 9:13 PM Phillip Hallam-Baker
wrote:
> Lets take a step back. There are two s
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Mar 1, 2021 at 5:27 PM Jim Manico wrote:
> Denis,
>
> > With OAuth, the RS must have a prior relationship with the AS (which is
> no
thing to do
is provide dynamic registration in OAuth. Will client developers do the
wrong thing, sure. Might it be challenging to support in a simple way,
maybe. But having the addition to OAuth to solve the problem is better than
nothing, and further it starts to change the mindset that dynamic
registration
AS to the table.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 24, 2021 at 5:34 PM Tim Bray wrote:
> The OAuth work has successfully built a perfectly reasonable syntax and
> protocol fo
, or is an OAuth WG
responsibility?*
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana
wrote:
> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>
> I wo
y to limit) which AS are allowed.
Would you agree with that statement?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 24, 2021 at 11:36 AM Carsten Bormann wrote:
> On 2021-02-24, at 11:22, Wa
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 24, 2021 at 10:09 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:
> Hi Phil,
>
>
>
> I am moving this to the OAu
Should we solve the NxM problem, and if so, how do you propose we do that?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 24, 2021 at 8:08 AM Bron Gondwana
wrote:
> On Wed, Feb 24, 2021,
by doing that. Are we hoping to change
something in particular, if so, what exactly is that? Is it the culture of
the group, how the OAuth specs are written, the goal of the WG, or
something else?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress
otocol?
Any additional information would be appreciated.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana
wrote:
> On Wed, Feb 24, 2021, at 00:13, Warren Parad
missing.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Tue, Feb 23, 2021 at 2:03 PM Bron Gondwana
wrote:
> (bringing this back to just the OAuth list)
>
> On Tue, Feb 23, 2021, a
You mean all but the access token and authorization code, right?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Feb 17, 2021 at 8:50 PM Dominick Baier
wrote:
> Well. Maybe it is at least wo
est/response data that is part of the attack. This doesn't increase
security, as a matter of fact, with regard to the RFC, we shouldn't talk
about security at all, since it has zero impact on it.
It is worth talking about that pattern as *one* possible solution to
maintaining sessions, but that's
Totally agree.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Feb 15, 2021 at 11:51 AM Neil Madden
wrote:
>
>
> On 15 Feb 2021, at 10:26, Philippe De Ryck <
> phili...@pragmaticw
dditional changes.
I assume there is a flaw in my reasoning somewhere, so please help me find
it.
- Warren
Warren Parad
Founder, CTO
On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci wrote:
> Let me rewind a bit here. This was never presented as driving use case.
>
>
>
>- Neil su
t). I don't see how this
affords an AS any additional freedom.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 8:39 PM Vittorio Bertocci <
vittorio.berto...@auth0.com> wr
That only applies to third party cookies, it shouldn't affect third-party
iframes as far as I'm aware. So unless we expect those to break, we
probably shouldn't include that as a driving use case. Is there another
measure that would be relevant here?
Warren Parad
Founder, CTO
Secure your user
the
owner of the back-channel), what's the benefit of specifying the explicit
endpoints necessary for the BFF to have?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sl
redirect_uri and use PKCE via the code verifier.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov
wrote:
> Thanks a lot for your answer Neil,
&g
Why doesn't PKCE help for authentication?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 2:48 PM Stoycho Sleptsov
wrote:
> I would like to add my reasons about
>
> Can you expand on what silent authentication and session token stands for
> here? If you are referring to the iframe scenario, the new browser measures
> make it problematic.
Which new browser measures?
Warren Parad
Founder, CTO
Secure your user data and complete your a
auth
doesn't technically support) it will always be available to Javascript in
browser, right?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 1:06 PM Dominick Baier
wrote:
> Hi,
&
ver (nor common), and then we
should challenge the need to directly provide an RFC recommendation for
handling this.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 14, 2021 at 12:29 PM Vi
s can use the JWT found in the
HttpOnly SameSite=Strict cookie as a security measure against XSS attacks
that attempt to exfiltrate access tokens. That's a potential suggestion I
would favor, although I still can't know if that solves the problem being
presented in the draft.
- Warren
Warren Parad
Fou
refresh tokens to be introspected can also create a conflict with
> the sec recommendation to rotate them
Not following, can you explain this further?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On
to the AS?
Even if you can justify access tokens, there currently isn't evidence
provided why we should explicity discourage.
On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt
wrote:
>
>
> Am 08.02.2021 um 00:56 schrieb Warren Parad :
>
>
>
>> I‘m therefore leaning towards e
encourage that?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.
On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt wrote:
> Hi Andrii,
>
> Am 07.02.2021 um 21:30 schrieb Andrii Deinega :
>
>
ould still make this change valuable?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.
On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt wrote:
> +1
> ᐧ
>
> On Tue, Dec 8, 2020 at 4:51 AM Rifaa
mechanism would be required. Perhaps I'm missing something though.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.
On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett wrote:
> Hi all,
>
>
client_id is not used. Which would mean breaking for that type of
grant wouldn't it?
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.
On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov
wrote:
> +
token possible locations (i.e. Header and Body), to what I assume
is to implicitly say *Don't use a query parameter*. It also suggests *Don't
use a cookie at all*, even with* SameSite=Strict*. Although maybe that is
the point.
For my reference, what makes a *new feature* and what makes *an OAu
token, but no
matter, if I'm having this thought, then surely others have it as well,
right?
[image: image.png]
Warren Parad
Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.l
to the
code grant flow. It's confusing to see these numerical identifiers twice in
the same picture. But maybe there is something hidden in this that I'm
missing, still 3a and 3b could be used to identify different legs of the
same code path.
[image: image.png]
*Warren Parad*
Secure your user data
s have it as well,
right?
[image: image.png]
*Warren Parad*
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.
<https://rhosys.ch>
On Wed, Jul 15, 2020 at 7:55 PM Dick Hardt wrote:
> +1
>
> On Wed, Jul 15, 2020 at
Why is #3 a problem, and why do the admin A incorrectly use App A to store
the service credentials of App B in their repository? Admin A should be
using their source control/database to store the tenant B client secret.
*Warren Parad*
Secure your user data and complete your authorization
something. Given the example I
provided, would you be able to provide more insight into the problem you
are seeing?
*Warren Parad*
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.
<https://rhosys.ch>
On Mon, Jul 13, 2020
101 - 183 of 183 matches
Mail list logo
