Indeewari,
I'm confused regarding what you are describing. Would you be able to give
additional context?
- Warren
On Fri, Aug 2, 2024 at 11:25 AM Indeewari Wijesiri
wrote:
> Hi all,
>
> Refresh token rotation, which involves issuing a new refresh token each
> time an access token is renewed, i
I think I'm missing 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&g
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
this thought, then surely others 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
) relevant 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*
S
earer 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 <htt
o detail a list of possible
RS bearer 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,
ent_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:
&
ndary 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,
&g
brought up that would 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, 2
not 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 :
ens 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 le
o it.
Allowing 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://authre
ilt our AS we
explicitly added this so that services 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 p
(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
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:
>
>
> 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
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 abou
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,
>
t from 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:2
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
S
that don'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
y to make any additional 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.
>
>
>
&g
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
request/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 sessi
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 worth w
re
out what I'm 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
on protocol?
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
o accomplish 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. Imp
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,
👏
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
hout the
ability 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-2
AP to solve, 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:
ing to bring
custom unverified 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 reasonab
us right 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 dynam
👏
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
g number + account
Id deplorable, 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:
> Let
is cumbersome
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
n 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 dat
💯
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
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 imp
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, is.
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 aut
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
Authr
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
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
Any 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 an
he AS to revoke directly 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:
>
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. Pa
to make from the start is
> 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:
>
&g
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
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
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
don't
see 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
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
ual points 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 argu
ike to see at least a partial 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.
'd 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?
W
s is a viable
solution, "because 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
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,
lement 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
limiting and (5) to be easy to allow
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 W
ch 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:
> Speci
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.io
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
r 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
does 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, A
onvinced of this actually solving the PoP situation 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 nee
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 authoriz
s, and 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 <
> Therefore, in my opinion, the 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.
>>
>>
ab issue
<https://gitlab.com/gitlab-org/gitlab/-/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
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
nized 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
m accidentally being
abused".
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 P
s to the AS, we should directly 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
e one doing 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
Foun
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 problem, a
as 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 wit
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://aut
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
e of OAuth that neither 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
Fo
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.io/>
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
ven if you give the access
token to a malicious actor, they can't do anything with it. Removing the
need for the AS to care about DPoP in any way is a huge win.
I'm sure I missed a critical part of this somewhere, so I would appreciate
any insight others have.
- Warren
Warren Parad
Fo
buses-open-authentication-advanced-social-engineering-attacks.html
If we can't protect against these latter ones, I hardly think protecting
against the former is useful/interesting/valuable.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authr
should keep the user
there for user's protection. Any AS redirecting the user to an invalid
redirect url, isn't doing the right thing.
But that only solves the illegitimate phishing urls, it doesn't solve the
class of problem where a phishing application is legitimately registered.
lock these.
Phishing can still use PKCE and PAR, nor does WebAuthN provide protection
from this problem.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Sat, Dec 18, 2021 at 4:11 PM George Fletcher wrote:
&
I'm not following to be honest. Could you detail concretely what the flow
would be that would result in vulnerability?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Jan 5, 2022 at 1:41
tate mismatch.
It doesn't matter if the request isn't protected against CSRF, because no
valid token is going to be returned anyway.
So I don't think there is an issue here, did I get that correct?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. I
such as not needing a backend service, requiring the
utilization of the nonce, incorrect usage of the *id_token* to name a few.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Jan 19, 2022 at 1
ded.
Amanda, please complete the registration.
- Warren
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Mon, Jan 24, 2022 at 11:09 PM Amanda Baber via RT <
drafts-expert-review-comm...@iana.org>
nd I would interpret all
other tokens as justifications for returning a 4XX status code.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev wrote:
> Hi and sorry f
Can you link them here?
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Sun, Jan 30, 2022 at 9:47 PM RFC ISE (Adrian Farrel) <
rfc-...@rfc-editor.org> wrote:
> Hi OAuth,
>
> The authors o
It may help to specifically clarify which interaction with the AS are we
talking about here.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Fri, Feb 4, 2022 at 10:16 AM Johannes Koch wrote:
> Hi the
I also agree that there hasn't been sufficient review of this document to
warrant progressing it.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Fri, Feb 4, 2022 at 6:56 PM David Chadwick
Then perhaps what is in order is to replace 7638, before moving forward
with this one, that way we don't end up in state where implementations are
based on unnecessary complexity which isn't backwards compatible.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as
I'm a big fan of not arbitrarily adding security to paths that don't
require it. The more complicated it is to do what you want without a
concrete reason, the more likely there will be an introduced vulnerability.
Consistency on adding requirements to endpoints that don't need it also
makes them h
This is a great improvement.
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.
On Tue, Feb 15, 2022 at 2:37 PM Neil Madden
wrote:
> Thanks, these changes address my comments. I am happy with the new dra
e isn't
enough value in there to list them any more than there is value in listing
OIDC providers that support OAuth. Being met with a list of hundreds of
libraries and packages doesn't make for a good experience, and do those
same developers know if they need PKCE, EdDSA signatures, a lib
1 - 100 of 194 matches
Mail list logo
