As a co-author of the draft, I believe we've addressed all the first WGLC
comments and that this is ready for publication. Thanks!
Aaron
On Wed, May 15, 2024 at 9:05 AM Michael Jones
wrote:
> Having addressed the first WGLC comments in -04 and adding a pretty
> diagram in -05, I believe this
Thanks for writing this up! I remember talking about this with you at a
past IETF meeting.
I agree this is a useful profile for this ecosystem. I would be happy to
help with this document, as well as help prepare a presentation on this at
the next IETF meeting.
---
Aaron Parecki
On Thu, May
ble. It is a work
> item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title: The OAuth 2.1 Authorization Framework
>Authors: Dick Hardt
> Aaron Parecki
> Torsten Lodderstedt
>Name:draft-ietf-oauth-v2-1-11.txt
>Pages:
ell
>
>
>
> On Wed, May 1, 2024 at 11:43 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote:
>
>> Thanks Rifaat,
>>
>> The editors have just published draft -18 addressing the comments from
>> Justin Richer's and Andy Barlow's reviews.
>>
&g
Hi all, in preparation for WGLC, I added an SVG version of the flow diagram
to the HTML version of the draft, but no other changes were made. Thanks!
---
Aaron Parecki
On Fri, May 3, 2024 at 4:38 PM wrote:
> Internet-Draft draft-ietf-oauth-resource-metadata-05.txt is now availa
Thanks Rifaat,
The editors have just published draft -18 addressing the comments from
Justin Richer's and Andy Barlow's reviews.
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-18.html
Aaron
On Wed, May 1, 2024 at 5:51 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a
wrong by finding the respective section in the RFC
> would be easy, but I did not find any statement to support my view.
>
>
>
> Am 2024-02-27 00:19, schrieb Aaron Parecki:
>
> This errata should be rejected.
>
> The client credentials grant results in an access token is
This errata should be rejected.
The client credentials grant results in an access token issued to
the client that presented credentials. There is no mechanism for "Client A"
to request a token for "Client B" using the client credentials grant, since
the credentials themselves are what determines
ps
> Authors: Aaron Parecki
> David Waite
> Philippe De Ryck
>Name:draft-ietf-oauth-browser-based-apps-16.txt
>Pages: 59
>Dates: 2024-02-16
>
> Abstract:
>
>This specification details the threats, attack consequences, se
lient to resend the token request after a specific
> time so that user interaction can complete on the second device.
>
>
>
> The shortcut by directly calling the Token endpoint has a few advantages:
>
>
>
>- No iframe with redirect which might end up in a failure not
>
tity-chaining/issues/60> (1 by
>bc-pi)
>- #45 Consider limiting token formats to JWT
><https://github.com/oauth-wg/oauth-identity-chaining/issues/45> (1 by
>bc-pi)
>
> 4 issues closed:
>
>- #69 Add Aaron Parecki to acknowledgements section
>
e the only
one for the foreseeable future then I'd like to continue working on the
draft as is.
So please let me know if you have anything in mind that could leverage
client-initiated POST requests. Thanks!
---
Aaron Parecki
___
OAuth mailing list
OAut
This errata should be rejected, as section 4.2.2.1 is about the implicit
flow, which returns parameters in the fragment part of the URL, not query
parameters.
On Wed, Nov 29, 2023 at 11:51 AM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:
> The following errata report has been submitted
I support adoption. The draft lays out an application of several existing
OAuth building blocks. I have some additional use cases for the pattern
that are not yet mentioned in the draft and am planning on discussing them
with the authors.
Aaron
On Tue, Nov 14, 2023 at 4:59 AM Rifaat Shekh-Yusef
about any additions to the Security BCP at
> this point. It is very easy to re-start the "one more thing" loop we've
> been stuck in for the last years. There may be more useful things to say,
> but we should put them on the list for a future second version of the BCP.
>
> -Daniel
I don't think the Security BCP should incorporate cookie best practices
directly in the document. If anything, it sounds like possibly a candidate
for inclusion in the Browser Apps BCP.
There are already some mentions of these cookie properties mentioned in the
Browser Apps BCP, though only in
txt is now
> available. It
> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
>
>Title: OAuth 2.0 for Browser-Based Apps
> Authors: Aaron Parecki
> David Waite
> Philippe De Ryck
>Name:draft-ietf-oauth-browser-b
Tobias, Paul, Christian,
I just noticed the new working group adopted version of this draft:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
I posted this comment on Github, but I'll repeat it here for others. I find
the new name "OAuth Status List" confusing. While I understand
sed in this revision:
https://github.com/aaronpk/oauth-first-party-apps/milestone/2?closed=1
I look forward to continuing the discussion at IETF 118!
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
the feedback from the list and publishing a new draft before IETF 118.
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I support adoption
On Sat, Sep 30, 2023 at 5:53 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for adoption for the *JWT and CWT Status List*
> draft:
> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/
>
> Please, reply *on the mailing list *and let us
I disagree with this errata. The original text is correctly representing
that the "photo-sharing service" trusts the authorization server. The
suggested text is ambiguous because it does not make clear which party is
trusting which other party.
Aaron
On Sun, Sep 17, 2023 at 11:00 AM RFC Errata
I agree with this errata, it should have been "authorization code". This
sentence was also removed from OAuth 2.1, since the PKCE code
challenge/code verifier mechanism is a more complete protection against
authorization code substitution.
Aaron
On Tue, Sep 5, 2023 at 6:00 AM RFC Errata System
ep them safe is on the same level, but
> their safety is always relative. They make any attack worse, indeed (and
> that is also true for BFFs in some scenario's). This isn't specifically
> about BFFs.
>
> Le lun. 28 août 2023 à 17:38, Aaron Parecki a écrit :
>
>> > BFFs a
;>> with actual code, and as such create a shorter, simpler, but more
>>>>> constructive discussion?
>>>>>
>>>>> The demonstration in its current form would not lead to a successful
>>>>> compromise of a good implementation of access tokens
Hi Jaimandeep,
As with many OAuth extensions, this is not obligatory to implement unless
you need the functionality it provides. Many of the concerns you mention
are referenced in the security considerations section of the draft already,
and we would of course be happy to further expand that
y on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
> Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.iet
Hi Philippe, I look forward to discussing this with you at the OAuth
Security Workshop later this month. Like I mentioned to you last year, I
want to make sure your concerns are adequately captured in the document.
The goal for this draft is not to present the one "best" architecture for
I like it, it's definitely the best out of the list.
Aaron
On Thu, Jun 15, 2023 at 7:57 AM Pieter Kasselman wrote:
> Hi folks, one of the discussion points at IETF 116 for the cross-device
> security BCP was finding a collective name for the exploits of the cross
> device flows we were seeing.
Hi Warren, this is described in detail in the linked paper on page 31 if
you need further clarification.
Aaron
On Wed, Jun 14, 2023 at 7:36 AM Warren Parad wrote:
> That doesn't make sense to me.
>
> On Wed, Jun 14, 2023, 21:31 Daniel Fett 40danielfett...@dmarc.ietf.org> wrote:
>
>> Hi
I've created a pull request to update this section here:
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/82/files
Aaron
On Wed, Jun 14, 2023 at 6:47 AM Aaron Parecki wrote:
> Hi Alex,
>
> I see what you mean, in Section 4.4.1 with the implicit flow, the sequen
Hi Alex,
I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
ends with the redirect back to the client from H-AS with the access token.
Steps 5 and 6 don't happen with the implicit flow, so "works as above"
isn't descriptive enough.
The paper describes a slightly different
This errata is incorrect and should be rejected. RFC7523 defines two
separate uses of JWTs, one is client authentication and the other is an
authorization grant. When using RFC7523 as client authentication, you can
use any type of authorization grant, including the token exchange grant.
See
because I just checked the
in-progress OAuth 2.1 draft (which updates RFC6750) and it still references
the older RFC7235, so I will go update that to reference RFC9110 instead.
Thanks,
---
Aaron Parecki
On Tue, Apr 4, 2023 at 10:19 PM Mark Nottingham via Datatracker <
nore...@ietf.org> wrote:
>>>
>>>> *Friday*
>>>>
>>>>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>>>>- *Cross Device Flow –* Pieter (15 min)
>>>>- *Identity Chaining *– Rifaat/Pieter (20 min)
>>>>- *Native Apps U
Since that is my comment referenced in the OpenID thread, I should clarify
that my intent was to have this language in the Security BCP with the
caveat that it's only applicable if your AS intends on supporting SPAs. In
other words, we're not saying all ASs SHOULD add CORS headers, only ASs
that
There is no situation in which supporting arbitrary redirects (whether from
the OAuth redirect URI or within your own app) is a good idea.
This is known as an Open Redirector, and is the basis of many attacks on
OAuth as well as other things unrelated to OAuth. OWASP has a cheat sheet
about this
I have also seen what you describe in 2, as well as a variation of that,
which is to encode the redirect in the "state" parameter, as described
(briefly) in RFC6749 https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.2
Note that using "state" to carry this redirect should only be done with a
he developer can do themselves.
---
Aaron Parecki
On Mon, Feb 27, 2023 at 2:29 AM Oliva Fernandez, Jorge
wrote:
> Hi Jaimandeep,
>
>
>
> Just about the last point:
>
>
>
> "Remote assertion server" is not a new concept and is already widely used
> to prevent c
Here's a version of this that my colleague wrote up in August for this
grant, we're definitely interested in exploring this further. It is also
missing the nonce/server challenge part, but it's a start.
https://github.com/jaredhanson/id-oauth-fido2/blob/main/draft.txt
Aaron
On Fri, Dec 23,
There is significant overlap between this draft and the concepts brought to
the OAuth WG at the last IETF meeting by Ben Schwartz, which he also
presented to the HTTPAPI WG. After that meeting, I volunteered to work with
Ben on adapting his concepts to a model that would fit better within the
.
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
hese types of privacy and security
considerations of any form of this type of unregistered OAuth client.
Aaron Parecki
On Tue, Dec 13, 2022 at 9:30 AM Dmitry Telegin wrote:
> Hello Tobias, thanks for the draft! In regards to prior art, I'd like to
> mention Solid Project and their OI
ft:
https://drafts.oauth.net/oauth-browser-based-apps/draft-ietf-oauth-browser-based-apps.html
Aaron
On Wed, Dec 7, 2022 at 12:52 AM Thomas Broyer wrote:
>
>
> On Wed, Dec 7, 2022 at 1:07 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>>
else I
am planning on adding to the document. Please review if you are interested
and let me know if you have any further suggestions!
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I support adoption of this document.
Aaron
On Wed, Nov 16, 2022 at 7:52 AM Mike Jones wrote:
> I support adoption of the cross-device flows document.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth *On Behalf Of * Joseph Heenan
> *Sent:* Wednesday,
-13
Is this a "MUST" or a "must"?
"to learn the user data" - this sounds awkward, should it be "the user's
data"? Not sure if there is a better suggestion.
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
cial record.
Thanks,
Aaron Parecki
On Tue, Sep 13, 2022 at 10:42 AM wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title : OAuth 2.0 fo
o avoid misinterpretations in the
>>>> future?
>>>>
>>>> Best Regards,
>>>> Mikheil Kapanadze
>>>>
>>>>
>>>>
>>>> ___
>>>> OAuth mailing list
>
to be both
accessible (online) by the client as well as aware of the request. These
are both properties avoided by the SD-JWT draft, perhaps these can be
clarified in the introduction.
Aaron Parecki
On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <
d.w.chadw...@verifiablecredentials.info>
The discussion yesterday was about the redirect_uri parameter at the token
endpoint, not at the authorization endpoint.
The redirect_uri parameter at the authorization endpoint is currently:
* optional if the client has only one redirect URI registered
* required if the client has multiple
rectories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title : The OAuth 2.1 Authorization Framework
> Authors : Dick Hardt
> Aaron Parecki
> Torsten Lodderstedt
I will follow up with you off-list to chat further, thanks!
Aaron
On Thu, Jun 16, 2022 at 5:50 AM Yannick Majoros wrote:
> Hello Aaron,
>
> I'd be happy to contribute. What would be an appropriate time to talk
> about this?
>
> Thanks
>
> Le jeu. 16 juin 2022 à 04:56
>>> security issues involved and their impact. I do also have POCs and further
>>>> documentation for each solution, along with attack descriptions and their
>>>> mitigations.
>>>>
>>>> > Did you consider using a service worker or oth
Hi Yannick, answers inline:
> There is a lot of debate around the question. Are these really security best
> practices?
The intent of this draft is to document the best practices today. If
anything in the document is not the best way to do something given the
documented constraints, then that
I see how this could be confusing, so I'll make a note to clarify it.
However, the only two error codes that would be returned from the
authorization endpoint would be HTTP 200 or 302, because this is always
returned to the browser, not to the OAuth client.
In the case of the authorization server
That doesn't have the literal string "S256", only the full name.
On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell wrote:
> I think
> https://www.iana.org/assignments/named-information/named-information.xhtml
> maybe has what you're looking for.
>
> On Fri, Feb 4, 2022, 6:33 PM Mike Jones
I don't think this is actually the best place to reference, but S256
already exists in the registry established by RFC7636 (PKCE):
https://datatracker.ietf.org/doc/html/rfc7636#section-6.2
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pkce-code-challenge-method
The
t always be practical (e.g. one-time
>> use in a certain timeframe etc).
>>
>>
>>
>> The addition of these mitigations is not meant to replace the need for
>> one-time use or good logging hygiene. Instead they provide pragmatic
>> defence in depth against real a
I tend to agree with Neil here. I'm struggling to see the relevance of this
attack.
It seems like the PDF writeup describes two possible reasons an attacker
could get access to the authorization code and PKCE code verifier.
1. The attacker has access to the logs of the token endpoint.
2. The
The grace period is not about the refresh token lifetime, it's specifically
about whether what would be a single-use refresh token can be used more
than one time within a short window of the first use.
Okta supports a configurable grace period per application that the customer
can set, anywhere
designing from a defence in depth perspective is a good practice, so why
> not give implementors options (and guidance) to add additional layers of
> defence to match their risk profiles?
>
>
>
>
>
> *From:* OAuth *On Behalf Of *Sascha Preibisch
> *Sent:* Wednesday 13 Oc
not less challenging than managing authorization codes on
> the server side, preventing reuse of them.
> With that in mind I am not sure if I follow the given argument. I would
> prefer to keep MUST as it is today.
>
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki wrote:
>
>
lid token?
>
> 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 10:33 PM Aaron Parecki wrote:
>
>> Aside from the "plain" method, the
second time if the one
> time use requirement is removed. Is there another countermeasure in PKCE
> that would prevent it? For example, an attacker may obtain the
> Authorization Code and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
see
>> announcements for new globally-consistent high-scale cloud database
>> services every day - is this really that hard to implement?
>>
>> — Neil
>>
>> On 13 Oct 2021, at 18:41, Aaron Parecki wrote:
>>
>>
>> Warren, I didn't see you on the inte
as it
doesn't provide any additional benefit.
If anyone can think of a possible attack by allowing authorization codes to
be reused *even with a valid PKCE code verifier* then that would warrant
keeping this requirement.
---
Aaron Parecki
On Wed, Oct 13, 2021 at 10:27 AM Warren Parad wrote
man/listinfo/oauth
>>
>>
>> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe
>> <https://preferences.forgerock.com/>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://w
: Dick Hardt
> Aaron Parecki
> Torsten Lodderstedt
> Filename: draft-ietf-oauth-v2-1-04.txt
> Pages : 85
> Date: 2021-10-05
>
> Abstract:
>The OAuth 2.1
.
>> Given Justin and Annabelle are also part of the OAuth community, I'm sure
>> they will be considering how HTTP Sig can apply to OAuth, so the overlap is
>> serving us already.
>>
>> /Dick
>>
>>
>> ᐧ
>>
>> On Wed, Oct 6, 2021 at
I support adoption of this document.
- Aaron
On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> As a followup on the interim meeting today, this is a *call for adoption *for
> the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
> as a WG document:
>
publishing a new draft ahead of the upcoming interim
meetings. As always, feedback is greatly appreciated!
Thanks!
---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com
On Wed, Sep 8, 2021 at 2:06 PM wrote:
>
> A New Internet-Draft is available from the on-line Internet-
September.
> Please, let us know if you would like to present during one of
> these meetings.
>
> Regards,
> Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/l
I support the adoption of this document, it seems like a good starting
point for defining the link between HTTP Signatures and OAuth.
Aaron
On Mon, Jul 19, 2021 at 7:18 AM Justin Richer wrote:
> Needless to say, but as the author of both this draft and the draft that
> it would replace, I am
Honestly it didn't even occur to me that someone would try this, since the
entire point of the authorization endpoint is that it's the thing the
user's browser talks to. Adding MTLS just means you're going to have to
send the user to some other endpoint instead, which is then effectively
acting as
Not exactly. The thinking is by standardizing these endpoints in some way,
it would allow client library developers to write generic libraries that
can work with any backend.
On Mon, May 17, 2021 at 1:53 PM Warren Parad wrote:
> I can't follow the discussion. So I'm still missing why the
> If as mentioned in paragraph 4b. the source of the leak is the HTTP log
> of Authorization Request: why would not the attacker know the code
> verifier as well if Access Token Requests were logged too?
You're on the right track here. It's all about where the attacker is
sitting in the
BFF is that the common meaning is what the document calls
> Full BFF -- so what many readers will assume is BFF is not what the
> document is referring to.
> ᐧ
>
> On Tue, May 4, 2021 at 8:03 AM Aaron Parecki wrote:
>
>> I support adoption. I'm also fine with the BFF a
_
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Rock values your Privacy <https://www.forgerock.com/your-privacy>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing,
> Security Training
>
> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of
> mix-up attacks? Learn how to protect your client in our latest blog post on
> single
> sign-on:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>
> Hackmanit GmbHUniversitätsstraße 60
> <https://www.google.com/maps/search/Universit%C3%A4tsstra%C3%9Fe+60?entry=gmail=g>
> (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr.
> Christian Mainka, Dr. Marcus Niemietz
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Aaron
On Fri, Feb 26, 2021 at 1:36 PM David Waite
wrote:
>
>
> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki wrote:
>
> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
&g
Dynamic client registration does exist in OAuth:
https://tools.ietf.org/html/rfc7591
The point is that basically nobody uses it because they don't want to allow
arbitrary client registration at their ASs. That's likely due to a
combination of pre-registration being the default model in OAuth for
incide with the specifications might be in order.
>
> Just spend some time on https://stackexchange.com/filters/4229/oauth and
> you will see the issue and struggles.
>
>
> --
> -jim
>
> Jim Willeke
>
>
> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki wrote:
>
>
gt; which open dynamic client registration is not appropriate. JMAP could have
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
>
>
> — Neil
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy
, but that is an unofficial forum and will be seen by basically just
the authors.
---
Aaron Parecki
https://aaronparecki.com
On Wed, Oct 28, 2020 at 9:51 AM Roberto Polli wrote:
> Hi everybody,
>
> I'd like to provide some feedback to draft-ietf-oauth-v2-1. Is there a repo
> (eg. like https://github.com
Thank you Seán, this is an excellent analysis and makes this attack much
easier to understand. I completely agree with your rewritten text, both
that it better describes the situation as well as the conclusion that it
ends up being a bit too general for the BCP.
---
Aaron Parecki
https
authorization server.
More broadly, I would like to make sure the scope of the attacks that this
prevents is clarified so that people may better understand when they do not
need to worry about this and don't need to use this new parameter.
---
Aaron Parecki
https://aaronparecki.com
On Mon, Oct 26, 2020
rom people who
have already built refresh token rotation into a system.
Thanks!
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
dely used now, any thoughts on
> referencing the use of this as well for access token requests?
>
> Best Regards,
> Janak Amarasena
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-
changes reflect all the latest discussions we've had. There
are still some outstanding items I am aware of that need adding to the
document as well. Apologies for the delay in getting this out. I hope we
can pick up the momentum on this document again!
Aaron Parecki
On Fri, Oct 2, 2020 at 4:36 P
ract needs any qualification on this and would only confuse people
further. Any clarifications of which situations are appropriate for using
OAuth could be explored in a different section in the spec.
Aaron Parecki
On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt wrote:
> I agree. OAuth
I agree that there is nothing unique to PAR that would justify adding the
privacy considerations mentioned to that draft. I wouldn't oppose adding a
privacy considerations section to OAuth 2.1 though.
Aaron
On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt wrote:
> In the PAR meeting today, Denis
-response-mode/blob/master/spec.txt
This looks like a good starting point and I am happy to work with Jared on
refining this.
---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com
On Thu, Jul 30, 2020 at 1:55 PM Dick Hardt wrote:
> I hear you Jim, but it is not so much ru
I haven't seen any OAuth drafts that talk about sending OAuth access tokens
in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't
already exist, but this sounds like a good candidate to develop as an OAuth
extension.
---
Aaron Parecki
https://aaronparecki.com
https
uot;1/2/3" are really just a
single action as described by the "Note" below the diagram in your
screenshot.
---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com
On Thu, Jul 30, 2020 at 8:43 AM Warren Parad wrote:
>
> https://www.ietf.org/id/draft-ietf-oau
and
actually provides additional flexibility for the AS as well since that
endpoint no longer needs to be the exact same URL as the authorization
endpoint.
---
Aaron Parecki
https://aaronparecki.com
On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt wrote:
> I just thought about another option.
.
Oh, and +1 from me :-)
Aaron Parecki
https://aaronparecki.com
On Wed, Jul 15, 2020 at 11:57 AM Warren Parad wrote:
> I only recently joined this WG DL, so maybe this was already discussed by
> I have two things I'm confused/curious about:
>
> 1. Can we avoid using (1, 2, 3) on t
sers and
protect access to their resources. Obviously in order to do that the AS
must know about the details of the request.
Can you please clarify the scenario in which you would want the AS to have
no information about the request that it's authorizing?
Aaron Parecki
On Wed, May 27, 2020 a
and
code_verifier are always required.
That said, I do understand the previously discussed concerns around
existing OpenID Connect clients.
I believe the text that Daniel proposed is the best of both worlds, and I
support making this change in both OAuth 2.1 and the Security BCP.
Aaron Parecki
On Tue
nue to solve that problem its own way outside of OAuth without
conflicting with OAuth.
It's not useful to anyone to leave extension points open for hypothetical
solutions later when we already know of a solution that works for public
clients. At that point that should just be a new spec.
Aaron Parecki
On
1 - 100 of 229 matches
Mail list logo
