Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

le to read response data. On Thu, Feb 18, 2021 at 5:08 AM Neil Madden wrote: > Thanks for following up, Brian. Responses below. > > On 17 Feb 2021, at 22:48, Brian Campbell > wrote: > > Always appreciate (and often learn from) your insights, Neil. I'd like to > dig into t

Re: [OAUTH-WG] Digest for DPoP

My inclination is to keep digest[1] out of the base DPoP document. I do believe that including it would add unneeded complexity to regular old DPoP (there are some subtleties around digest that make it more complicated than one might expect) and, from a design philosophy perspective, DPoP has

Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token

Hi Adrian, I believe this work was presented briefly to the WG in London during IETF 101. As far as I can recall, the general reaction/thinking at that time was that the WG really should be working on a document about OAuth and single page applications (that may or may not include something like

Re: [OAUTH-WG] Authorization Header Encoding

AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to align with the token68 part of "credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1 (the draft that would become RFC7235 is referenced by RFC6750 in

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Always appreciate (and often learn from) your insights, Neil. I'd like to dig into the CSRF thing a bit more though to understand better and hopefully do the right thing in the draft. It seems to me that a GET at the bff-token endpoint is "safe" in that it's effectively just a read. There could

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > We did attempt to capture the assumptions in the draft but clearly could have done a better job with it :)

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > >Title : OAuth 2.0 Rich Authorization Requests >Authors : Torsten Lodderstedt > Justin Richer >

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-06.txt

ew Version Notification for draft-ietf-oauth-par-06.txt A new version of I-D, draft-ietf-oauth-par-06.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-par Revision: 06 Title: OAuth 2.0 Pushed Authorizatio

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

m that perspective of not having a lot of optionality or switches. It is a nice feature to have, when possible. > Vladimir > > > On 12/12/2020 01:58, Brian Campbell wrote: > > Any type of client could use DPoP and (presumably) benefit from > sender-constrained access token

Re: [OAUTH-WG] PAR error for redirect URI?

And that's done: https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/ On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt wrote: > +1 for following Vladimir’s proposal > > > Am 14.12.2020 um 14:54 schrieb Brian Campbell 40pingidentity@dmarc.ietf.org>: >

Re: [OAUTH-WG] PAR error for redirect URI?

er, I mean an -05 On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell wrote: > Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll > add that to a -04. > > On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov < > vladi...@connect2id.com> wrote: > >

Re: [OAUTH-WG] PAR error for redirect URI?

ction URI, the > “invalid_request” error code can be used as the default error code.* > > Hope with this we can close the case. > > Vladimir > > On 04/12/2020 18:08, Brian Campbell wrote: > > > > On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov <

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

ds of abuse. > > XSS is game over no matter how you slice it. > > Crypto solutions do not help. Perhaps the world of OAuth can start > suggesting that web clients use CSP 3.0 in specific ways, if you still plan > to support Implicit type flows or tokens in browsers? > > Re

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

ing DPoP > for access tokens? Mobile apps? Clients using a Client Credentials grant? > > How are they impacted by any change made specifically for browser-based > applications? > > Philippe > > > On 9 Dec 2020, at 23:57, Brian Campbell > wrote: > > Thanks

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

t; On a final note, I would be happy to help clear up the details on > web-based threats and defenses if necessary. > > — > *Pragmatic Web Security* > *Security for developers* > https://pragmaticwebsecurity.com/ > > > On 8 Dec 2020, at 22:47, Brian Campbell > wrote: > >

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

Danial recently added some text to the working copy of the draft with https://github.com/danielfett/draft-dpop/commit/f4b42058 that I think aims to better convey the "nutshell: XSS = Game over" sentiment and maybe dissuade folks from looking to DPoP as a cure-all for browser based applications.

Re: [OAUTH-WG] Proposed changes to draft-ietf-oauth-dpop-02

attempts at replies are inline On Wed, Dec 2, 2020 at 8:42 AM Denis wrote: > I have reviewed the whole draft and you will find comments below starting > with five editorials comments. Every other comment is numbered. > Let us start with five typos where there is a duplication of the word >

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

support adoption On Tue, Dec 8, 2020 at 5:51 AM Rifaat Shekh-Yusef wrote: > All, > > This is a call for adoption for the following AS Issuer Identifier in > Authorization Response as a WG document: > > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ > > Please,

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

cently used jti values to prevent replay, rather than maintaining a >> separate list per client. That could perhaps be spelled out more clearly in >> the draft, as I think the entropy discussions only really make sense in >> that context. If the RS instead maintains a separate list

Re: [OAUTH-WG] DPoP followup II: confirmation style

On Thu, Dec 3, 2020 at 5:55 PM wrote: > I think this topic is related to the question of "followup I: freshness and > > coverage of signature". The option 2 for the followup I will also break > AS/RS > > symmetry. If we choose the option 2 for followup I, I think we might as > well > > choose

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

intains a separate list per client then a > simple counter is sufficient. > > — Neil > > On 2 Dec 2020, at 15:17, Brian Campbell < > bcampbell=40pingidentity@dmarc.ietf.org> wrote: > > The conversation at > https://github.com/danielfett/draft-dpop/pull/51#discussion

Re: [OAUTH-WG] PAR error for redirect URI?

rect URI at >>> the authorization endpoint. >>> >>> "If the request fails due to a missing, invalid, or mismatching >>>redirection URI, … authorization server ... MUST NOT automatically >>> redirect the user-agent to the >>>invalid red

Re: [OAUTH-WG] PAR error for redirect URI?

eil > > On 2 Dec 2020, at 23:28, Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >  > During the course of a recent OIDF FAPI WG discussion (the FAPI profiles > use PAR for authz requests) on this issue > <https://bitbucket.org/openid/fapi/issues/343/what-is-a

[OAUTH-WG] PAR error for redirect URI?

During the course of a recent OIDF FAPI WG discussion (the FAPI profiles use PAR for authz requests) on this issue it was noted that there's no specific error code for problems with the redirect_uri (the

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

The conversation at https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311 has a bit more of the rational behind the choice of 96 bit minimum. On Wed, Dec 2, 2020 at 7:07 AM Denis wrote: > Hi Daniel, > > All your arguments make sense. I agree. > > A minor point however. The size

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

Thanks Dick. On Tue, Dec 1, 2020 at 1:43 PM Dick Hardt wrote: > I have 2 suggestions for the draft that I beleive address the issues Denis > is bringing up: > > 1) call out that a DPoP proof can only be used once, and a new DPoP proof > is needed for every API call. Apologies if that is in the

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

Hi Denis, The choice to use "iat" vs. "exp" was made in the summer of last year. You can see some of the discussion from then in https://github.com/danielfett/draft-dpop/issues/38. I believe it pretty well has consensus at this point and thus unlikely to be changed. While I do believe there are

Re: [OAUTH-WG] Token substitution in DPoP

It took me some time to warm to the ECDH based idea but I do think it has a lot of merit. For whatever it's worth, I put the idea forth as one potential path forward during the general PoP interim meeting back in March (

Re: [OAUTH-WG] Token substitution in DPoP

On Tue, Nov 24, 2020 at 2:39 AM Daniel Fett wrote: > > The recommendation could be to use a fresh key pair for each token request. > > Public clients will have RTs bound so need to use the same key. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for

Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP

It's not a huge burden but does add some non-zero complexity to the protocol as well as size to the proof. And in my mind anyway, doing so would sort of beg the question as to having some similar treatment for authz codes and refresh tokens. Which can, of course, also be done. But adds more

Re: [OAUTH-WG] Token substitution in DPoP

The extent of the weirdness needed leads me to feel that it's not a threat that's in scope. To copy the proof signature from a request with T1 onto a new request using T2, Alice would need access to the first request, which is made directly from client to RS. That's not possible for a web server

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-dpop-02.txt

f the IETF. Title : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley Torsten Lodderstedt Mic

Re: [OAUTH-WG] PAR Shepherd Review

On Tue, Nov 10, 2020 at 2:44 AM Hannes Tschofenig wrote: > Hi all, > > > > I am in the process of writing my shepherd write-up for the PAR document > and wanted to make sure that I properly understand the document. > > The introduction says: > > > > “ > > > >This document [PAR] complements

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

On Tue, May 5, 2020 at 2:52 PM Brian Campbell wrote: > > >> 9.1: >> This would be a good place to mention BREACH as an example of how a DPoP >> proof (and AT) might leak, despite only being sent over a direct HTTPS >> channel. Note though that adding a rand

Re: [OAUTH-WG] DPoP and refresh tokens

d -- but > asymmetric cryptography is much stronger than a shared secret. Why > discourage its use? > > > > > ᐧ > > On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell > wrote: > >> I'm currently working on the draft and hope to have a new revision >> published rela

Re: [OAUTH-WG] DPoP and refresh tokens

I'm currently working on the draft and hope to have a new revision published relatively soon. Just the other day I made some changes to the text around RTs with https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974 that maybe/hopefully makes some of it more

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

I'd suggest removing the "of an OAuth authorization grant" bit from the abstract. The term 'authorization grant' has meaning from https://tools.ietf.org/html/rfc6749?#section-1.3 that doesn't really work there in the abstract. On Mon, Oct 26, 2020 at 8:33 AM Karsten Meyer zu Selhausen <

Re: [OAUTH-WG] New podcast on identity specifications

arely surface in a usable form to the people who > don’t participate in discussions. > > The first episode > <https://auth0.com/blog/identity-unlocked-explained-episode-1/>, > featuring Brian Campbell discussing MTLS & DPoP, should give you an idea of > what season 1 o

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

At some point I'm going to be among the lucky few who will be asked to review the JWT claims registration request. One of the criteria to consider is "whether the registration description is clear" and Logan's questions suggest that perhaps the descriptions of these claims are not sufficiently

Re: [OAUTH-WG] Updated shepherd writeup for draft-ietf-oauth-access-token-jwt-09

I believe the intent of that example was to show the unencoded header and body content of the JWT. So perhaps all that's needed is to adjust the text that introduces the example and the figure title or caption or whatever it's called to reflect that? On Mon, Sep 21, 2020 at 4:58 AM Hannes

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-04.txt

: Fri, Sep 18, 2020 at 6:20 AM Subject: New Version Notification for draft-ietf-oauth-par-04.txt To: Dave Tonge , Nat Sakimura , Torsten Lodderstedt , Filip Skokan , Brian Campbell A new version of I-D, draft-ietf-oauth-par-04.txt has been successfully submitted by Brian Campbell and posted

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

ot;tl;dr:"? (I read it, but I'm > not sure where you landed given your last sentence) > ᐧ > > On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit >>

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

te a little for the extra bulk). > > [1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114 > [2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html > > — Neil > > On 8 Sep 2020, at 23:46, Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >  &

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

Indeed there are cases, as you point out, where the key might be knowable to the server via some other means, which makes the "jwk" header in the DPoP proof not strictly necessary. And while omitting the key in such cases would reduce the size of some messages (the DPoP proof anyway), such

Re: [OAUTH-WG] WGLC Review of PAR

; > Am 03.09.2020 um 02:29 schrieb Justin Richer : > > > > Nice work, Brian. Looks good to me! > > ____ > > From: Brian Campbell [bcampb...@pingidentity.com] > > Sent: Wednesday, September 2, 2020 3:41 PM > > To: Justin Ric

Re: [OAUTH-WG] WGLC Review of PAR

Thanks Torsten, Taka, and Justin, I took the revised text from Justin and tweaked it with some typo cleanup and minor adjustments to make what is hopefully a final proposal below. I had a similar feeling about the last paragraph not really fitting but don't have a better location to suggest so am

Re: [OAUTH-WG] WGLC Review of PAR

a redirect from the browser, there is a >> good chance of a race condition where the same browser request is made more >> than once, for example, while the browser is loading the authorization URL >> at the AS, the user could refresh the page causing the authorization URL to >> be relo

Re: [OAUTH-WG] [Last-Call] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

+1 On Thu, Aug 27, 2020 at 8:20 AM Justin Richer wrote: > I would clarify that this doesn’t necessarily say that the user’s there, > and remove the normative requirement (which doesn’t have enforceable teeth > in this context): > > Implementers should be aware that a token introspection request

Re: [OAUTH-WG] WGLC Review of PAR

to a MUST. On Tue, Aug 25, 2020 at 4:57 PM Justin Richer wrote: > Hi Brian, just a couple responses inline where it seemed fitting. Thanks > for going through everything! > — Justin > > On Aug 25, 2020, at 6:01 PM, Brian Campbell > wrote: > > Thanks for the review and

Re: [OAUTH-WG] WGLC review of PAR

Thanks Neil. Appreciate the review and feedback. My attempts at responses are inline below. On Thu, Aug 20, 2020 at 5:30 AM Neil Madden wrote: > As promised in the last interim meeting, I’ve reviewed the current (03) > draft-ietf-oauth-par document. Overall it looks close to ready to me, with

Re: [OAUTH-WG] WGLC Review of PAR

Thanks for the review and comments Justin. Replies (or attempts thereat) are inline below. On Wed, Aug 19, 2020 at 2:06 PM Justin Richer wrote: > I’ve done a full read through of the PAR specification, and here are my > notes on it. > > For additional context, I’ve implemented this

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

Thanks for the review, Karsten. We'll incorporate your suggestions into the next revision of the draft. On Wed, Aug 19, 2020 at 3:41 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhau...@hackmanit.de> wrote: > Hi all, > > I have two very small suggestions which I also raised as issues on

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

A couple of WGLC comments from my sphere. I'd like to take the discussion of the first item in https://mailarchive.ietf.org/arch/msg/oauth/iD33QbZTj92LJ6M9wNUq9s3nLpA/ as a suggestion that the top part of section 2.1 be reworked

Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft

Thanks Joseph. We'll get those niggles addressed. And it's great to hear the positive implementation and testing info. On Wed, Aug 12, 2020 at 6:08 PM Joseph Heenan wrote: > Thanks Rifaat, Hannes, and also thanks to all the authors. > > I’ve been through the latest spec and it basically looks

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

xplicit typing. See the full PR at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source > diffs at > https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml. > Please review! > > This is

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

On Sat, Aug 15, 2020 at 3:08 AM Vladimir Dzhuvinov wrote: > Regarding the "sub != client_id" check -- could a simple rejection of all > JWTs with "sub" present suffice? > Prohibiting the use of "sub" in request object JWTs would suffice, yes. I'd suggested the more narrow/specific prohibition

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

While some discussion of why explicit typing was not used might be useful to have, that thread started with a request for security considerations prohibiting use of the "sub" with a client ID value. Because such a request JWT could be repurposed for JWT client authentication. And explicit typing

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

request objects. On Tue, Aug 11, 2020 at 4:27 PM Francis Pouatcha wrote: > Hello Brian, > > On Tue, Aug 11, 2020 at 5:55 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Hi Francis, >> >> My apologies for the tardy response to this - I was

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

Hi Francis, My apologies for the tardy response to this - I was away for some time on holiday. But thank you for the review and feedback on the draft. I've tried to respond inline below. On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha wrote: > Bellow is the only remark I found from reviewing

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

/oauth/FMljWETMEkGTI4pUluqIqtAJ_9A/ suggests changes to the draft should still be forthcoming. So also adding a brief statement to the security considerations doesn't seem inconceivable. On Thu, Jul 23, 2020 at 2:29 PM Brian Campbell wrote: > In hindsight, yeah, having explicit JWT typing everywh

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

I didn't have the reference offhand during the meeting today but https://tools.ietf.org/html/rfc6973 looks to be a good source of considerations for writing privacy considerations. As I mentioned, I've written a number of such sections. Though these probably shouldn't be considered exemplary they

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-par-03.txt

ization Requests Authors : Torsten Lodderstedt Brian Campbell Nat Sakimura Dave Tonge Filip Skokan Filename: draft-ietf-oauth-par-03.txt Pages :

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-02.txt

al the draft could do with some discussion of why an attacker > being able to modify an authorization request is a risk. I might just be > lacking enough coffee this morning to understand the risk here. > > — Neil > > On 22 Jul 2020, at 23:14, Brian Campbell 40pingidentity@dmarc.i

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

minick Baier > > On 23. July 2020 at 07:38:04, Dominick Baier (dba...@leastprivilege.com) > wrote: > > Good point. Thanks, Brian. > > We should retrofit typs everywhere..in hindsight. > > ——— > Dominick Baier > > On 22. July 2020 at 23:55:20, Brian Campbell (

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-02.txt

to the lifetime only, or to > the lifetime and the single use. > > > Vladimir > > > On 10/07/2020 21:36, Brian Campbell wrote: > > WG, > > A new -02 draft of "OAuth 2.0 Pushed Authorization Requests" has been > published. A summary of the changes, taken from

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

use a typ header as suggested by the JWT BCP? > > ——— > Dominick Baier > > On 22. July 2020 at 17:37:41, Brian Campbell ( > bcampbell=40pingidentity@dmarc.ietf.org) wrote: > > The TL;DR here is a somewhat tentative suggestion that a brief security > con

[OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

The TL;DR here is a somewhat tentative suggestion that a brief security consideration be added to https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ that prohibits the inclusion of a 'sub' claim containing the client id value in the request object JWT so as to prevent the request object JWT

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-02.txt

PM Subject: New Version Notification for draft-ietf-oauth-par-02.txt To: Filip Skokan , Torsten Lodderstedt < tors...@lodderstedt.net>, Brian Campbell , Dave Tonge , Nat Sakimura A new version of I-D, draft-ietf-oauth-par-02.txt has been successfully submitted by Brian Campbell and post

Re: [OAUTH-WG] Mix-Up Revisited

In my (probably simplistic) understanding of things, the root underlying issue that allows for mix-up in its variations is the lack of anything identifying the AS in the authorization response. Following from that, introducing and using an `iss` authorization response parameter has always seemed

Re: [OAUTH-WG] oauth - Not having a session at IETF 108

No OAuth WG sessions planned for the 108 meeting? On Fri, Jun 12, 2020 at 1:40 PM IETF Meeting Session Request Tool < session-requ...@ietf.org> wrote: > > > Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the > oauth working group does not plan to hold a session at IETF

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

The current draft (draft-ietf-oauth-dpop-01) does say that when a valid DPoP proof is presented and refresh token is issued to a public client, the refresh token must be bound to the DPoP key. So that part is already covered in the document. And, for whatever it's worth, that pretty closely

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

addition response fields for > the refresh token binding (e.g. "rt_token_type). > > Thanks, > George > > On 5/29/20 5:50 PM, Brian Campbell wrote: > > Apologies for the slow reply on this. No excuses other than life > > sometimes happens. > > `token_type` is maybe

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

Apologies for the slow reply on this. No excuses other than life sometimes happens. `token_type` is maybe not the clearest extension point (and one I've arguably misused in OAuth MTLS and the now defunct Token Binding

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18

Just wanted to note that there is a newer -01 revision of the document on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html On Wed, May 13, 2020 at 6:16 AM IESG Secretary wrote: > The Web Authorization Protocol (oauth) Working Group will hold > a virtual interim meeting on

Re: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics

I suspect it was an unintentional oversight in the Security BCP and that it should be updated to allow for it. On Mon, May 11, 2020 at 10:03 AM Aaron Parecki wrote: > The Security BCP has pretty clear language around requiring exact matching > of redirect URIs now. > > >

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

I think the point is that the Security BCP in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1 requires that the authz request has either the PKCE "code_challenge" or the OIDC "nonce". Whereas 2.1 in

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

n 6 can include such a contribution (e.g., a server generated nonce). > > > > Best, > > Nikos > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Friday, May 1, 2020 10:03 PM > *To:* oauth > *Subject:* [OAUTH-WG] Fwd: New Version Notification for > d

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

t'll go so far as to recommend it but can reword so that it doesn't imply incompatibility. > > 9.1: > This would be a good place to mention BREACH as an example of how a DPoP > proof (and AT) might leak, despite only being sent over a direct HTTPS > channel. Note though that adding a random

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

example, the message body or other request >headers." > > Again, I find this an awkward phrase, "the signature of the DPoP proofs > only contains the HTTP URI and method", and I think it' better to talk > about the JWT only containing these claims,

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

Version Notification for draft-ietf-oauth-dpop-01.txt > To: Torsten Lodderstedt , David Waite < > da...@alkaline-solutions.com>, John Bradley , Brian > Campbell , Daniel Fett , > Michael Jones > > > > A new version of I-D, draft-ietf-oauth-dpop-01.txt > has been s

Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

ones for the refresh token and access >token. People agreed that this deserves consideration. >- *Symmetric keys are significantly more efficient than asymmetric >keys.* In discussions between John Bradley, Brian Campbell, and Mike >Jones at IETF 106, John worked out h

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

Yeah, I hadn't really been thinking of going so far as making it RECOMMENDED either but more of just providing an easy option for those that would choose to use it. On Mon, Apr 27, 2020 at 10:58 AM Justin Richer wrote: > I agree that any URI could be used but that it MUST be understood by the

Re: [OAUTH-WG] PAR and client metadata

>> > >> > In a off-list conversation Torsten floated the idea of letting >> confidential PAR-only clients register without a redirect_uris and having >> this "PAR only" parameter will enable that. >> > >> > A "PAR only" parameter wi

Re: [OAUTH-WG] PAR - Can AS/client require request object?

While there are certainly different permutations and contexts of use that could be imagine, I tend to agree with Filip here in not seeing a strong need to define new PAR specific metadata around signing/encryption of the request object. On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan wrote: >

Re: [OAUTH-WG] PAR and client metadata

; > > > A "PAR only" parameter will also prevent client developers from > accidentally making plain authz requests (for clients that rely on PAR for > the extra security). > > > > Vladimir > > > > On 16/04/2020 18:39, Brian Campbell wrote: &

Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki wrote: > Thanks for the detailed review Brian! I've made many of these edits to the > draft, but there are still a few things that need some discussion on the > list. My notes are inline below. > Thanks Aaron. I realize there was a lot there. I've

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

This old thread https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/ has some discussion of working with/around that particular quirk of the htmlizing tool. On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci wrote: > Thank you for bringing this up Benjamin, you saved me from

Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

On Wed, Apr 22, 2020 at 5:36 PM Dick Hardt wrote: > Brian: many, many thanks for all the feedback! > You are welcome. I won't lie - it was not a quick exercise :) > > I did a quick skim of your comments, and will address the first and last > ones. > > On Tue, Apr 21,

Re: [OAUTH-WG] April 20th Interim Meeting Minutes

An action item coming out of this latest interim meeting was to propose some updated text for review on JAR to address the problem that PAR is currently facing where it can be interpreted that JAR says that the request_uri must refer to JWT. I've taken a stab at such an update and proposed text

[OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

Been working on this on and off for a while now (it's not exactly short at 80+ pages, various other priorities, etc.) but wanted to share my thoughts from an initial review of the OAuth 2.1 draft before the interim next week where it is on the agenda

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

I'd agree that Vladimir's proposed wording is more meaningful/helpful. On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvinov wrote: > Nat, John, thanks for updating the JAR spec. I just reviewed it, in > particular the authz request and the security considerations sections. > Choosing to make

Re: [OAUTH-WG] PAR and client metadata

; That is good and useful perspective, thanks for sharing that. Best, > *Filip* > > > On Tue, 14 Apr 2020 at 22:09, Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Using PAR can facilitate improved security by giving clients a >> (relatively) simple means

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

tp://twitter.com/aaronpk> > > > > On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell > wrote: > >> sec 4 does have "The resource server MUST reject any JWT in which the >> value of "alg" is "none".' >> >> On Thu, Apr 16, 2020 at 1:09 PM Aaron Par

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

sec 4 does have "The resource server MUST reject any JWT in which the value of "alg" is "none".' On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki wrote: > Section 2.1 says: > > > Although JWT access tokens can use any signing algorithm, use of > > asymmetric algorithms is RECOMMENDED > > Can this

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

ould really work or help the >> situation? > > > :facepalm: indeed, sorry. > > S pozdravem, > *Filip Skokan* > > > On Tue, 14 Apr 2020 at 23:39, Brian Campbell > wrote: > >> Hi Filip, >> >> My attempts at responses to your questions/comments are inli

Re: [OAUTH-WG] PAR and client metadata

rther limited to scenarios where the attacker does not need to > be able to redeem the authorization code themselves. What threats fall into > this category? > > — > Annabelle Backman (she/her) > AWS Identity > > On Apr 14, 2020, at 2:44 PM, Brian Campbell 40pingidentity@dm

Re: [OAUTH-WG] PAR and client metadata

you have already thought of a suitable name? :) > > Vladimir > On 14/04/2020 23:08, Brian Campbell wrote: > > Using PAR can facilitate improved security by giving clients a > (relatively) simple means for sending a confidential, integrity protected, > and (for confidential

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

Hi Filip, My attempts at responses to your questions/comments are inline: On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan wrote: > I've wondered about the decision to use a new scheme before > > but > this time i'd like

[OAUTH-WG] PAR and client metadata

Using PAR can facilitate improved security by giving clients a (relatively) simple means for sending a confidential, integrity protected, and (for confidential clients anyway) authenticated authorization request. It seems like some of that improved security could be undermined by a malicious

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

One of the primary motivations for the proof-of-possession mechanism of DPoP being at the application layer was to hopefully enable implementation and deployment by regular application developers. A lesson learned from the difficulties and lack of adoption around Token Binding was that access to

<    1   2   3   4   5   6   7   8   9   10   >