I have started implementing OAuth 2 on geoloqi.com's API. I have a
question/suggestion regarding using refresh tokens.
It is my understanding that access tokens are supposed to be short-lived,
and clients should use the refresh token to request a new access token after
it expires. When the client
Hi folks,
I'm implementing OAuth 2 for my project (geoloqi.com) where I have some
mobile phone clients needing to authenticate. I'm using the password grant
type for these clients. Even though the call to the token endpoint is going
over HTTPS, I'm still slightly concerned about sending the
setting on which hashing the password makes security sense is
# to use hashed passwords for low-security low-privilege interfaces
# (e.g. tweeting) and to require raw passwords for
# high-security high-privilege interfaces (such as configuration
changes.)
On 2010/09/07 12:09, Aaron
Jitesh,
See section
5.1.2http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-5.1.2of
the Draft 11 spec which provides a way to exchange the resource
owner's
username and password for an access token. This is probably what you're
looking for.
Aaron
On Wed, Jan 12, 2011 at 1:22 PM,
tokens.
Aaron Parecki
On Fri, Aug 12, 2011 at 8:10 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
OAuth allows a client to access user resources without revealing the
resource owner's identity to the client. Isn't this anonymity? I consider
this an important property of the protocol
that opening an
external browser is better because the user may already be signed in in
that session?
Aaron Parecki
Geoloqi.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
That seems like a good idea, but then it should also be explicitly stated
what to do if the server issues non-expiring tokens.
aaronpk
On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer e...@hueniverse.com wrote:
How do you feel about changing expires_in from OPTIONAL to RECOMMENDED?
EHL
...@hueniverse.com wrote:
Hmm. This might become too much work at this stage…
** **
Happy for suggestions but I won’t pursue it on my own for now.
** **
EHL
** **
*From:* Aaron Parecki [mailto:aa...@parecki.com]
*Sent:* Monday, January 16, 2012 10:36 PM
*To:* OAuth WG
*Cc:* Richer
I believe this one https://github.com/quizlet/oauth2-php is the most
up-to-date PHP library, although you might check around for forks of it
since I haven't checked up on it in a month or so.
Aaron Parecki
On Wednesday, February 29, 2012, Pete Clark wrote:
Hey all, I've joined the list
I believe this one https://github.com/quizlet/oauth2-php is the most
up-to-date PHP library, although you might check around for forks of it
since I haven't checked up on it in a month or so.
Aaron Parecki
On Thu, Mar 1, 2012 at 2:44 AM, Pete Clark p...@appmuscle.com wrote:
Hey all, I've
available in public services that I could poke at as well.
Thanks!
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I recently moved the site to a new server and this was a misconfiguration.
It's fixed now, thanks!
For future reference, you can suggest any edits to the website here:
https://github.com/aaronpk/oauth.net
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Wed, May 21
I'm not sure what article you're referring to, but feel free to add the
article and send a pull request to oauth.net:
https://github.com/aaronpk/oauth.net
Here's an example of the PR for the Authentication article that Justin
added: https://github.com/aaronpk/oauth.net/pull/81
Aaron Parecki
of this, I believe the phrase or exceeds the scope granted by the
resource owner. is unnecessary, since there is no initial grant by the
resource owner. Am I reading this correctly, or is there some situation I
am not thinking of? Thanks!
Aaron Parecki
aaronparecki.com
@aaronpk http
is helpful.
That said, I also agree with William's assessment.
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Tue, Jul 21, 2015 at 4:05 PM, William Denniss wdenn...@google.com
wrote:
We had a good sync on this topic offline on Monday, and it seemed the
consensus
fish against the resource server. In fact, if the resource server
queries the introspection endpoint to check if tokens are valid, then that
effectively gives an attacker a way to fish for tokens using the resource
server's credentials.
---
Aaron Parecki
http://aaronparecki.com
On Sat, Jul 18, 2015
is valid and find out the user ID associated with it?
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote:
Because the target isn’t the client, it’s the protected resource. We’re
re-using OAuth’s client
by clients to verify if a
token is valid and find out the user ID associated with it?
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer jric...@mit.edu wrote:
Because the target isn’t the client, it’s the protected
e end-user code and
prompts the end-user to grant the client's access request."
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net
> wrote:
> FYI: A couple of us got together a
.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Wed, Nov 4, 2015 at 4:44 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net
> wrote:
> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
&
Thanks, the refresh grant was the case I was missing.
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Tue, Jul 7, 2015 at 8:13 AM, John Bradley ve7...@ve7jtb.com wrote:
In sec 6 you can send scope to down scope a refresh token.
In that case if the client asks
4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3
Aaron Parecki
aaronparecki.com
@aaronpk http://twitter.com/aaronpk
On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso asa...@adobe.com wrote:
hi Aaron
On Jul 7, 2015, at 6:23 AM, Aaron Parecki aa...@parecki.com wrote:
Section 5.2
If you send me a short sentence I can add a note on the oauth.net site with
this information as well.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Tue, Jan 12, 2016 at 7:52 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi all,
>
&
/XQJ4e_kgBOfn3tkTBXf6bYVNGJE
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Thu, Feb 18, 2016 at 12:34 AM, Mike Jones <michael.jo...@microsoft.com>
wrote:
> Thanks to William Denniss for creating the initial working group version
> of the OAu
it up right now.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Thu, Apr 7, 2016 at 9:38 AM, Mike Jones <michael.jo...@microsoft.com>
wrote:
> I am strongly against creating a 2.1 spec until we have at least a year of
> deployment experience with
implementation of a server that implements the device flow is here,
although it actually acts as a proxy for existing OAuth services:
https://github.com/aaronpk/TVAuthServer
Cheers!
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Fri, Apr 15, 2016 at 8:24 PM, Oli Da
net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>
<https://github.com/aaronpk/oauth.net>https://github.com/aaronpk/oauth.net
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Fri, Jul 8, 2016 at 6
ut I don't
actually know what I would implement after reading this.
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Wed, Feb 1, 2017 at 3:48 PM, Thomas Hardjono <hardj...@mit.edu> wrote:
>
> Folks,
>
> This may be of interest. Its forwa
flow is a good idea anyway, especially as these
single-page apps start to look more and more like native apps.
Basically I'm struggling to think of a reason to recommend using the
Implicit flow when it's not much harder to use the authorization code flow
in the first place.
Aaron Parec
horization code flow with no secret, and even better to use PKCE for
browser-based apps?
Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ink that's a sign that it's a
better recommendation than the implicit flow for JS apps.
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier <dba...@leastprivilege.com>
wrote:
> Given a solid client library for
-scale
deployments of this to know whether polling is even a problem in the first
place.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Fri, Oct 21, 2016 at 3:23 PM, Hanne
a traditional flow without any
special instructions to the user.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bbu...@redhat.com> wrote:
> Has anybody done any spec work around doing oauth from command line
>
, to ensure a secure
implementation in browser based apps.
Thanks in advance for your review and feedback!
Aaron Parecki
aaronpk.com
On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig
wrote:
> Hi all,
>
> Today we were not able to talk about
> draft-parecki-oauth-browser-based-ap
Thanks for the review, Christian! Responses inline. Changes have been made
on my GitHub version, not yet published as a new revision on ietf.org.
https://github.com/aaronpk/oauth-browser-based-apps
On Tue, Nov 27, 2018 at 1:45 AM Christian Mainka wrote:
> Hi Aaron,
>
> I just reviewed the
based-apps
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell
wrote:
> I would also like to see something to that effect. I feel that sometimes
> because SPAs use APIs, there's an unchallenged assumption that OAuth
er based proxy. So they see it as the
> same.
> >
> > Perhaps it is perspective.
> >
> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki > In this type of deployment, as far as OAuth is concerned, isn't the
> backend web server a confidential client? Is there even an
credentials to fall under the umbrella of
this BCP.
Aaron Parecki
aaronparecki.com
On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt
wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
>
> All Angular
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
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 response type? Are you aware of
> any OAuth (not OIDC) clients that do this t
wledgments section
* Fixed working group name and target status
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
worth pointing out.
Lastly, minor nit, I see the comment about changing occurrences of "SHALL"
to "MUST", but the new refresh token section still has two uses of "SHALL".
Thanks! Overall I'm happy to see this guidance!
Aaron Parecki
aaronparecki.com
On Tue, N
flow and
refresh tokens.
Aaron Parecki
aaronparecki.com
On Tue, Nov 20, 2018 at 12:38 PM George Fletcher wrote:
> Hi Torsten,
>
> This is the module I much prefer. By default all refresh_tokens are bound
> to the user's authenticated session. When the authentica
Agreed with 4. Since the security BCP is deprecating the implicit flow, it
seems like it's not worth the effort to try to come up with a solution for
this when the security implications of doing this aren't clear yet either.
Aaron Parecki
aaronparecki.com
On Tue, Nov 20, 2018 at 11:36 AM
My understanding was that the scope of the discussion was limited to OAuth,
and does not cover OpenID Connect ID Tokens. With that in mind, I support
the recommendation to use the authorization code instead of the implicit
flow.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.
e and published an updated
version:
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01
Thanks for the feedback so far.
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
escription is fine, and I don't disagree
> that some authorization servers may want to treat these clients in a
> different way.
>
> Thanks,
> George
>
--
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Thank you for the thorough review, Torsten! I've made these changes to my
working copy on GitHub but have not yet published an updated draft. My
responses are inline below. For any of your points that don't have a
response from me, I will address those separately but wanted to get this
out with
ormat JSON error,
> possibly with a standardized code - but again I don’t think the currently
> registered codes would be appropriate for conveying that.
>
> That said, I don’t know what interest there would be in standardizing such
> codes, considering the existing recommendations agains
the recommended
practice here? Thanks!
Aaron
--
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
conds for this and all subsequent requests.
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15#section-3.5
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Mon, Jun 3, 2019 at 9:55 AM Janak Amarasena
wrote:
> Hi Joseph,
>
> Thank you for the infor
I would like to discuss OAuth for browser based apps. I will be publishing
a new version in advance of the meeting.
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01
Aaron Parecki
On Mon, May 27, 2019 at 5:04 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> Please, le
These edits are currently in my source file on GitHub,
https://github.com/aaronpk/oauth-browser-based-apps as I believe it's no
longer possible to publish an updated version to ietf until after the
meeting.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On
er to need to make a request to an API, which then may need to
be able to get a new access token, which is effectively offline access.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Tue, Jul 9, 2019 at 9:16 AM George Fletcher wrote:
> I'll just add a couple more
code flow with no modifications
needed, (getting the authorization code back in the query string rather
than modifying it to use the fragment), since the Session History API can
be used to remove it from the URL. I've updated the section to clarify
that, so thanks!
----
Aaron Parecki
aaronparecki.com
@aaro
ecisions that could not be made by a refresh against the token
> endpoint.
>
> I’d be interested in hearing how strong of an implementation issue this
> might be for deployments - I could see a non-security argument that the BCP
> should only have one recommended approach here, and
on this as well.
Thanks!
Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Not to be pedantic, but adding OAuth support is a mechanism in support
of a goal. What's the end goal?
* Letting third party apps use the datatracker API?
* Letting people sign in to other apps with a datatracker account?
Aaron Parecki
aaronparecki.com
On Sun, Aug 18, 2019 at 2:05 PM Salz
e guidance on refresh tokens in browser-based apps. Maybe leaving
the mention of rotating the refresh token on every use, but I'm inclined to
remove the "SHOULD NOT issue refresh tokens" statement in order to leave
room for DPoP or similar in the future.
Sound reasonable?
Aaron Pare
": "5035678642",
"userinfo": "https://authorization-server.com/user/5035678642;
}
}
A more detailed analysis of the specific proposal and motivation behind
this is available on my blog:
https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
understanding is that only the mailing list is the "official" or "on the
record" medium, so discussion has to happen here.
The changes mentioned here are now pushed to my GitHub version.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On
Is it worth pursuing this to try to find an OAuth-based solution for this
particular architecture? (The app, AS and RS share a common domain, and
there is no backend other than the RS.) Something like a cookie-based OAuth
flow?
Aaron Parecki
aaronparecki.com
@aaronpk
Aaron Parecki
aar
ipts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?
Aaron Parecki
aaronparecki.com
@aaronpk
On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
wrote:
>
> Hey,
>
> Just read the spec - good to see the progress
Ok thanks for the input here everyone. I'm not seeing much of a consensus,
but these are all excellent points and I've collected them for discussion
during the meeting on Friday.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Mon, Jul 22, 2019 at 8:12 AM T
consensus on, so I've prepared those
points to talk about during the session on Friday.
Aaron Parecki
aaronparecki.com
@aaronpk
Aaron Parecki
aaronparecki.com
@aaronpk
On Wed, Jul 24, 2019 at 7:17 PM wrote:
>
>
> A New Internet-Draft is available from the on-line Interne
using
opaque tokens. Is that the intent? If so, probably better to just say
"should use opaque tokens" instead. Or this could refer to the steps
described later in this section, in which case should say "below".
> Possible measure include
should be "measures"
This may als
We'll be so productive with only 4 hours of darkness every day!
All of the dates work for me, but I would prefer the July dates since
it'll be easier/cheaper to bundle the two trips into one. (Hopefully
we could get the OAuth meeting dates early in the week at IETF then)
On Thu, Jul 25, 2019 at
s explicitly to allow the use of structured
values for the request_uri? From the introduction:
> but it also allows clients requiring an even
> higher security level, especially cryptographically confirmed non-
> repudiation, to explicitly adopt JWT-based request objects.
Aaron Par
orge described, so I would be happy if:
* the example in this draft of the GET request was an example with no PII
* there was an additional example using PAR that includes the full
bank account transfer in the current draft
----
Aaron Parecki
aaronparecki.com
On Thu, Sep 26, 2019 at 6:42 PM Justin Ri
om number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.
That's all for now, thanks!
Aaron Parecki
aaronparecki.c
this!
Aaron Parecki
aaronparecki.com
On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
wrote:
>
> Hi all,
>
> I just published a draft about “OAuth 2.0 Rich Authorization Requests”
> (formerly known as “structured scopes”).
>
> https://tools.ietf.org/html/draft-lod
and let me know what you think! I think this is
shaping up quite nicely now.
Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
still requiring a random value in the "state"
parameter, or adding some guidance on how to link a redirect response
with an authorization request.
Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
quot;MUST
NOT". This could use some clarification on what it means exactly when
an AS advertises support for incremental authz. If this value does not
mean the "existing_grant" parameter is supported, do we instead need
some other way to indicate which type of incremental authz is
supported for public
to handle a recommendation.
> 9.7. Content-Security Policy
> I think it should explicitly state the policies that should NOT be allowed
I'll bring this up in the next meeting.
Thanks for the feedback!
Aaron Parecki
aaronparecki.com
On Tue, Aug 6, 2019 at 8:20 PM Emond Papegaaij
wrot
,
agenda details, and links to all the draft specs that will be
discussed. I thought this might be helpful to others as well.
Hope this helps!
Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo
is especially problematic because of the way PKCE works where
clients have no indication as to whether the server supports PKCE if
the whole flow is successful.
I guess I just would rather not mention the possibility of using
static state values again.
Aaron Parecki
aaronparecki.com
I support the adoption of PAR.
Aaron Parecki
On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a call for adoption of for the OAuth 2.0 Pushed Authorization
> Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
>
I'm interested as well.
Aaron Parecki
On Wed, Oct 16, 2019 at 3:54 AM Torsten Lodderstedt
wrote:
> Hi,
>
> I’m interested.
>
> kind regards,
> Torsten.
>
> > On 15. Oct 2019, at 17:44, Hannes Tschofenig
> wrote:
> >
> > Hi all,
> >
>
Works for me, sounds like that clears up the confusion I am worried about.
Aaron
On Mon, Nov 25, 2019 at 7:12 AM Daniel Fett wrote:
> Am 16.11.19 um 14:28 schrieb Aaron Parecki:
>
> Thanks for the reply. You're right, PKCE requires maintaining
> application state as well, an
and resource indicators to mint RS-specific, privilege restricted, short
> lived access tokens.
> >
> > Do you think we should spell this out in the SPA BCP?
>
> I think that would certainly be a great start.
>
> -- Neil
> ___
Are the meeting minutes posted anywhere? I haven’t been able to find a link
to them yet. Thanks!
Aaron
--
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m
+1, I'm only comfortable making recommendations in this BCP if they
are in fact, the best current practice. In my mind that means nothing
aspirational, only things that are well established and that people
can act on today.
Aaron Parecki
aaronparecki.com
On Mon, Nov 25, 2019 at 12:50 PM
have to protect
> against a stronger threat model in which we assume that TLS security has
> been lost.
>
> -- Neil
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
only thing that most closely fits their existing model. It seems like we'd
be better off defining a new extension that captures the use case people
are actually doing, instead of encouraging the continuing use of the
password grant for this purpose.
Aaron Parecki
aaronparecki.com
@aaronpk <http
the
case, it sounds like that might be a new pattern that could be worth
documenting as well, if that's a common pattern others have
implemented and have good suggestions for.
Aaron Parecki
aaronparecki.com
@aaronpk
Aaron Parecki
aaronparecki.com
@aaronpk
On Fri, Feb 21, 2020 at
describe
the attacks, I've updated the text to hopefully clarify that. I've
also added a new header structure here which should help make that
relationship between the paragraphs more apparent.
> 9.8.5. Countermeasures – The phrase “using the authorization code with PKCE
> avoids these attacks”
0pm Monday, and I've
reserved 3:30-5:00pm for the side meeting.
https://trac.ietf.org/trac/ietf/meeting/wiki/107sidemeetings#point1
----
Aaron Parecki
aaronparecki.com
@aaronpk
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
gt; ___
> 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
>
kens via the implicit grant.
So my question for the list is am I forgetting about some way to
prevent this attack in OAuth? If not, can we rephrase this section of
the Security BCP to better clarify the intent here?
Aaron Parecki
aaronparecki.com
__
ce is unavailable, the whole system is
>>> unavailable. If there are separate keys, then a failure in one component
>>> does not fail the entire system.
>>>
>>> Well you can run more than one instance - it’s a completely stateless
>>> service.
I would like to discuss the Browser app BCP as well as the new draft which
got bumped from the agenda in Singapore:
https://tools.ietf.org/id/draft-parecki-oauth-client-intermediary-metadata
Aaron Parecki
aaronparecki.com
On Mon, Jan 20, 2020 at 7:34 AM Rifaat Shekh-Yusef
wrote:
>
we should accept this design assumption, in the same way we
>>> should accept form encoding as request format instead of JSON, for OAuth
>>> 2.0 extensions.
>>>
>>> OAuth 3.0 could explicitely be developed with different architectures in
>>> mind.
>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I support the adoption of this document.
Aaron Parecki
aaronparecki.com
On Mon, Jan 6, 2020 at 11:38 AM Rifaat Shekh-Yusef
wrote:
>
> All,
>
> This is a call for adoption for the OAuth 2.0 Rich Authorization Requests
> document.
> https://datatracker.ietf.org/doc/draft
> The Security BCP recommends S256.
Is a recommendation enough to change the default? That's definitely
normative changes from PKCE. I could be convinced either way, but it
would be the first place that 2.1 deviates from the combination of the
RFCs and BCPs.
----
Aaron Parecki
aaronparecki.
ifferent from
what is described in PKCE. If this is a good idea to change the
default, then that should be included in the Security BCP and brought
into 2.1 from there.
Aaron Parecki
aaronparecki.com
@aaronpk
On Thu, Mar 12, 2020 at 12:22 PM Pedro Igor Craveiro e Silva
wrote:
>
>
> P.S. This notice was also posted at https://self-issued.info/?p=2063
>> and as @selfissued <https://twitter.com/selfissued>.
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> h
th-security-topics]
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
I'm excited for the direction this is taking, and it has been a
pleasure working with Dick and Torsten on this so far. My hope is that
this first draft can serve as a good starting point for our future
discussions!
help simplify the AS, since simple string matching
is sufficient now.
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>
On Wed, Apr 8, 2020 at 3:01 PM Francis Pouatcha wrote:
> There is a lot of effort associated with the handling and correct
>
ant to consolidate the best practices across
the existing OAuth 2.0 documents, and is explicitly not intended to define
any new behavior that is not already in an adopted document, we can't
accept your suggestion of adding a new OTP-based grant in this document.
----
Aaron Parecki
aaronparecki.com
@aaronpk &l
1 - 100 of 230 matches
Mail list logo
