Re: [OAUTH-WG] Fwd: IETF 116 Preliminary Agenda

Hi Rifaat, I'm flying back on Friday. I therefore would ask you to schedule the slot I asked for on Tuesday. best regards, Torsten. On Feb. 25 2023, at 12:01 am, Rifaat Shekh-Yusef wrote: > Based on the preliminary agenda, we have two official sessions: > Tuesday and Friday, both at

Re: [OAUTH-WG] IETF-116: Client/Trust Management

Thanks!Am 31.01.2023 um 18:36 schrieb Rifaat Shekh-Yusef :Hi Torsten,Sounds good. I will add this topic to the list.Regards, RifaatOn Tue, Jan 31, 2023 at 11:18 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote:Hi Rifaat, Kristina and I would like to give an update to the WG about chal

[OAUTH-WG] IETF-116: Client/Trust Management

Hi Rifaat, Kristina and I would like to give an update to the WG about challenges and developments on client/trust management in the context of decentralized identity at IETF-116. We would seek the WG's feedback on our current ideas how to cope with them. We also think some of the ideas could

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

Hi Robert, Thanks for your review. > Am 15.12.2022 um 11:37 schrieb Robert Wilton via Datatracker > : > > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-rar-20: No Objection > > When responding, please keep the subject line intact and reply to all > email

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

Hi Eric, > Am 15.12.2022 um 11:33 schrieb Éric Vyncke via Datatracker : > > Éric Vyncke has entered the following ballot position for > draft-ietf-oauth-rar-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-rar-19: (with COMMENT)

Hi Murray, thanks for you review. I updated the draft based on it and submitted -20 Here is the diff https://author-tools.ietf.org/iddiff?difftype=--hwdiff=draft-ietf-oauth-rar-20.txt > Am 15.12.2022 um 09:34 schrieb Murray Kucherawy via Datatracker > : > > Murray Kucherawy has entered

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-rar-15

Hi Carl, thanks for your review comments. > Am 16.11.2022 um 12:25 schrieb Carl Wallace via Datatracker > : > > Reviewer: Carl Wallace > Review result: Has Nits > > Comments/questions > - Section 2.2 states "When different common data fields are used in > combination, the permissions the

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

+1 I support adoption of this draft. > Am 22.11.2022 um 01:44 schrieb Justin Richer : > > I support adoption of this draft. It’s important work that affects a number > of areas in and around OAuth. > > — Justin > >> On Nov 15, 2022, at 6:43 AM, Rifaat Shekh-Yusef >

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

>> -Original Message- >> From: Torsten Lodderstedt > <mailto:tors...@lodderstedt.net>> >> Sent: Tuesday, October 18, 2022 9:00 AM >> To: Roman Danyliw mailto:r...@cert.org>> >> Cc: oauth@ietf.org <mailto:oauth@ietf.org>; Brian Campbell

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

Hi Roman, thanks for you review. I’m trying to do the next round for the outstanding issues you raised. > Am 15.09.2022 um 00:30 schrieb Roman Danyliw : > > Hi! > > I performed an AD review of draft-ietf-oauth-rar-12. Thanks for this > document. My feedback is as follows: > > **

Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

Hi, the consent is not bound to the code. As you correctly pointed out, the code is a temporary artifact. It’s purpose is to bridge insecure frontchannel communication to more secure backchannel communication. You don’t need to preserve the code in order to preserve the consent. The code is

Re: [OAUTH-WG] DPoP - IPR Disclosure

I also am unaware of any IPR. best regards, Torsten. > Am 11.08.2022 um 05:54 schrieb David Waite > : > > I also am unaware of any IPR. > > -DW > >> On Aug 10, 2022, at 3:37 PM, Rifaat Shekh-Yusef >> wrote: >> >> Daniel, Brian, John, Torsten, Mike, and David, >> >> As part of the

Re: [OAUTH-WG] Call for adoption - SD-JWT

That might be the reason why ISO mDL uses expiration (I guess weeks to month) instead of revocation. And the wheel starts to turn again … > Kind regards > > David > > On 02/08/2022 10:47, Torsten Lodderstedt wrote: >> >>>> Am 02.08.2022 um 11:06 schrieb Wa

Re: [OAUTH-WG] Call for adoption - SD-JWT

> Am 02.08.2022 um 11:44 schrieb David Chadwick > : > > > > On 01/08/2022 18:39, Warren Parad wrote: >> So the question is how many offline interactions are there, and what do >> those look like? > This to me is the key question. If the vast majority of transactions between > the

Re: [OAUTH-WG] Call for adoption - SD-JWT

reaming API would include the data needed there (e.g. authorised channel lists and so on). > > On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt > <mailto:40lodderstedt@dmarc.ietf.org>> wrote: > > >> Am 02.08.2022 um 10:48 schrieb Warren Parad >> mailt

Re: [OAUTH-WG] Call for adoption - SD-JWT

; configuration? > What does that look like? > >> On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt >> wrote: >> >> >>>> Am 02.08.2022 um 10:35 schrieb Warren Parad >>>> : >>>> >>>  >>> Why would we not include

Re: [OAUTH-WG] Call for adoption - SD-JWT

e for of user claims, e.g. a sub, in most cases some privileges/roles. Please take a look at https://www.rfc-editor.org/rfc/rfc9068.html for best current practice. Using a VC in the way I described means the original AS doesn’t need to be involved in the issuance of the actual access tok

Re: [OAUTH-WG] Call for adoption - SD-JWT

e for of user claims, e.g. a sub, in most cases some privileges/roles. Please take a look at https://www.rfc-editor.org/rfc/rfc9068.html for best current practice. Using a VC in the way I described means the original AS doesn’t need to be involved in the > >> On Tue, Aug 2, 2022 a

Re: [OAUTH-WG] Call for adoption - SD-JWT

> Am 02.08.2022 um 09:53 schrieb Warren Parad > : > >  > If we are in a offline scenario how does the verifier got ahold of the public > key associated with the id token? Why id token? I would assume we are talking about verifiable presentations, right? There are a couple of ways to

Re: [OAUTH-WG] Call for adoption - SD-JWT

+1 > Am 29.07.2022 um 03:13 schrieb Brian Campbell > : > >  > I support adoption. > >> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef >> wrote: >> All, >> >> This is a call for adoption for the SD-JWT document >> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

sed confusion already, we should change the text. > > Maybe it should have been an editorial errata rather than technical. > > On Tue, Jul 19, 2022 at 7:44 AM Torsten Lodderstedt <mailto:tors...@lodderstedt.net>> wrote: > I’m not sure this requires an update. It bas

Re: [OAUTH-WG] [Technical Errata Reported] RFC9126 (6711)

I’m not sure this requires an update. It basically says „stick the uri you get from step 1 into this parameter in step 2“. Does this really require use to re-state any further requirements of a proper JAR? > Am 19.07.2022 um 15:15 schrieb Rifaat Shekh-Yusef : > > + Roman and Paul > > On Mon,

Re: [OAUTH-WG] OAuth 2.0 Rich Authorization Requests (RAR): Implementation Status

Hi, the yes ecosystem (1200 IDPs) uses RAR for authorising payment initiation and qualified electronic signatures. The Cloud Signature Consortium included RAR as means to authorise electronic signature to the v 2.0 of its API for remote signature creation

Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Rich Authorization Requests

I am not aware of any IPR that pertains to this specification. > Am 06.04.2022 um 15:34 schrieb Hannes Tschofenig : > > Authors, > > as part of the shepherd write-up, all authors of draft-ietf-oauth-rar must > confirm > that any and all appropriate IPR disclosures required for full

Re: [OAUTH-WG] WGLC for DPoP Document

I support publication of this specification. > Am 30.03.2022 um 09:18 schrieb Steinar Noem : > > I support publication of the specification > > ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge >: > I support publication of the specification > > On Wed, 30 Mar

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

I support publication. > On 24. Feb 2022, at 17:45, John Bradley wrote: > > I support publication. > > -- Original Message -- > From: "Rifaat Shekh-Yusef" > > To: "oauth" mailto:oauth@ietf.org>> > Sent: 2/21/2022 10:12:00 AM > Subject: [OAUTH-WG]

Re: [OAUTH-WG] draft-ietf-oauth-rar-08 review

Hi Hannes, > Am 21.12.2021 um 13:06 schrieb Hannes Tschofenig : > > Hi all, > > thanks for writing this document. I have read through it as part of my > shepherd writeup and here are a few comments and questions. thank you very much for your thorough review. We have tried to incorporate

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

I support adoption. > Am 14.01.2022 um 17:36 schrieb Mike Jones > : > >  > I support adoption. This specification solves the need for having a key > identifier that is also a URI. > >-- Mike > > From: OAuth On Behalf Of Rifaat

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

I think there are two options: 1) validation of the organization/person behind a certain client in order to be able to go after them in case of abuse 2) don’t redirect in an error condition However, even a successful OAuth process can result in a phishing attack. So I don‘t think (2) will help

[OAUTH-WG] GAIN Digital Trust

Hi all, as requested in the OAuth office hour yesterday, I would like to share a link to the GAIN site. At https://gainforum.org/ you can find the whitepaper written by more than 150 experts suggesting to built a global network of identity providers. The network

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

s. > 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 > Brian Campbell >

Re: [OAUTH-WG] OAuth Interim Meetings

Hi, we would like to give an update on RAR. best regards, Torsten. > Am 05.09.2021 um 05:19 schrieb Aaron Parecki : > > I would like to present on OAuth 2.1. > > Separately, and preferably later in the series, I would like to present on > the Browser App BCP. > > Thanks! > > Aaron > > >

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

more clear that it is allowed to do > so, and that the Token Response doesn't prevent the issued token from > containing sensitive data. > > /Jacob > > > Den lör 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt > mailto:tors...@lodderstedt.net>>: > The AS int

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

The AS intentionally shares the list of accounts in the mentioned example with the client. The assumption is the client asks for access to some accounts and the user decides which accounts to grant the client access to. This means the AS is authorized by the user to share this data. The

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

Hi Ash, > Am 31.08.2021 um 02:42 schrieb Ash Narayanan : > > Hi Dick, > > >The access token represents the authorization to access the resource(s) -- > >it does not represent the authorization to manipulate tokens. > > Anything for which the client must have an access token to access is a >

Re: [OAUTH-WG] RAR WGLC comment

ort such change. > > Odesláno z iPhonu > >> 19. 6. 2021 v 15:36, Torsten Lodderstedt >> : >> >>  >> Hi Brian, >> >> the idea was to use resource indicators as convenient short cut to support >> audience restricted access tokens. Howev

Re: [OAUTH-WG] WG Last Call on the RAR Document

Dear Dave, thanks a lot for your review! I create a PR with the changes you proposed. https://github.com/oauthstuff/draft-oauth-rar/pull/75 Please review and comment/approve. > Am 08.06.2021 um 12:33 schrieb Dave Tonge : > > Dear RAR

Re: [OAUTH-WG] RAR WGLC editorial feedback

Thanks Brian. Review and approved. > Am 17.06.2021 um 21:27 schrieb Brian Campbell > : > > In a PR to try and make it easy > https://github.com/oauthstuff/draft-oauth-rar/pull/74/files#diff-cbb16c6731a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66b > >

Re: [OAUTH-WG] RAR WGLC comment

Hi Brian, the idea was to use resource indicators as convenient short cut to support audience restricted access tokens. However, I agree this can be achieved by specifying authorization details in the token request as well. So I‘m fine with dropping resource indicators for RAR at all. This

Re: [OAUTH-WG] Can a client send the Authorization Request?

Hi, > Am 25.05.2021 um 16:59 schrieb A. Rothman : > > Hi, > > In RFC 6749 section 4.1, the Authorization Code Grant flow starts with: > > (A) The client initiates the flow by directing the resource owner's > user-agent to the authorization endpoint. The client includes > its

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

tf-oauth-rar-05.txt > Datum: 15. Mai 2021 um 20:34:13 MESZ > An: Brian Campbell , Justin Richer > , Torsten Lodderstedt > > > A new version of I-D, draft-ietf-oauth-rar-05.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. >

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

Hi, I have read the document and have no concerns. As an editorial feedback, I would suggest to drop „ If implemented correctly,“ in the abstract since this apparently is a prerequisite for all kinds of security controls ;-) best regards, Torsten. > Am 01.05.2021 um 22:47 schrieb Rifaat

[OAUTH-WG] authorization_details token request parameter and comparison in RAR

Hi all, in the recent RAR session, we started a discussion about an authorization_details token request parameter. This parameter would allow us to solve several outstanding topics: - Let the client determine what privileges to assign to the first access token issued in exchange for an

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: IPR Confirmation

Hi Hannes, I‘m not aware of any IPR related to this draft. best regards, Torsten. Filip Skokan schrieb am Mi. 24. März 2021 um 21:25: > Hello Hannes. I am not aware of any IPR related to this document. > > Cheers, > Filip > > Odesláno z iPhonu > > 24. 3. 2021 v 20:52, Hannes Tschofenig : > >

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

ion is informed by the client’s request data. So both concepts are complementary in my opinion. > > RAR probably just isn't applicable in that kind of case. > > > > Any idea how to consider these two edge cases? > > > > Best regards. > /Francis >

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

m. I am not opposed, but > before venturing into that we wanted to see what the reaction would be. > > On 2/14/21, 11:45, "Torsten Lodderstedt" > wrote: > >Hi Vittorio, > >thanks for the explanation. Do you assume the frontend passes the code o

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

it might look at first glance. I am > totally open to it, just making sure we understand what it can buy us. > > On 2/14/21, 06:11, "Torsten Lodderstedt" > wrote: > >Hi, > >I’m trying to understand your proposal. > >Section 1.2, bullet (

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

Hi, I’m trying to understand your proposal. Section 1.2, bullet (B) states (B) If the backend does not already have a suitable access token obtained in previous flows and cached, it requests to the authorization server a new access token with the required characteristics,

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

s to provide a similar JSON response to a query with the refresh token, > why not encourage that? Why should we encourage it? > > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. Implement > Authress. > >

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

e used with refresh tokens. best regards, Torsten. > > Regards, > Andrii > > >> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt >> wrote: >> Hi Andrii, >> >> thanks for your post. >> >> The draft is intended to provide AS and

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

gt; 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 >

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

Hi Andrii, thanks for your post. The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the

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

 > Am 14.12.2020 um 17:39 schrieb Brian Campbell > : > >  > 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’

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

;> Rifaat >>> >>> >>> On Thursday, December 3, 2020, Filip Skokan wrote: >>> To be clear, I'm not advocating to skip the registration, just wanted to >>> mention a potential concern. If the process allows it and it will not >>> introduce mor

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

Hi Neil, thanks for your comprehensive answers. Please find my comments inline. best regards, Torsten. > Am 12.12.2020 um 21:11 schrieb Neil Madden : > >  > Good questions! Answers inline: > >>> On 12 Dec 2020, at 10:07, Torsten Lodderstedt >>> wrote: >

Re: [OAUTH-WG] Detailed review of OAuth2.1

Thanks as lot Vittorio! You gave us a lot of homework but I think the draft will be improved a lot based on it. Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit (response type „id_token“ or „code id_token“) as there are examples in the wild where the id_token is used

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

Thanks for sharing, Neil! I‘ve got some questions: Note: I assume the tokens you are referring in your article are OAuth access tokens. - carrying tokens in URLs wie considered bad practice by the Security BCP and OAuth 2.1 due to leakage via referrer headers and so on. Why isn’t this an issue

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

I support the WG adoption of this draft. > Am 08.12.2020 um 13:50 schrieb Rifaat Shekh-Yusef : > > All, > > This is a call for adoption for the following AS Issuer Identifier in > Authorization Response as a WG document: >

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

prepared > proofs to talk to the AS to keep on refreshing the AT and use it against the > RS. When the value of the token is part of the proof, i cannot pre-generate > them for future issued access tokens. Short `iat` based windows don't help > here. > > S pozdravem, > Filip Sko

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

Hi, I'm failing to understand why binding the proof to the access token ensures freshness of the proof. I would rather think if the client is forced to create proofs with a reasonable short lifetime, chances for replay could be reduced. Beside that as far as I remember the primary replay

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

> Am 03.12.2020 um 09:56 schrieb Filip Skokan : > > There are several documents already mentioning "invalid_redirect_uri" as an > error code, specifically RFC7519 and OpenID Connect Dynamic Client > Registration 1.0. But these don't register it in the IANA OAuth Extensions > Error Registry,

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

@ietf.org > Subject: New Version Notification for draft-ietf-oauth-rar-03.txt > Date: 18. October 2020 at 18:17:55 CEST > To: "Brian Campbell" , "Torsten Lodderstedt" > , "Justin Richer" > > > A new version of I-D, draft-ietf-oauth-rar-03.txt > ha

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-jwt-introspection-response-10.txt

ork item of the Web Authorization Protocol WG of the IETF. > >Title : JWT Response for OAuth Token Introspection >Authors : Torsten Lodderstedt > Vladimir Dzhuvinov > Filename: draft-ietf-oauth-jwt-i

Re: [OAUTH-WG] Implementation questions around refresh token rotation

. > > -DW > >>> On Oct 12, 2020, at 03:15, Torsten Lodderstedt >>> wrote: >>> >>> >>>> Am 12.10.2020 um 09:04 schrieb Dave Tonge : >>>> >>>  >>> Hi Neil >>> >>> > refresh token

Re: [OAUTH-WG] Implementation questions around refresh token rotation

> Am 12.10.2020 um 09:04 schrieb Dave Tonge : > >  > Hi Neil > > > refresh token rotation is better thought of as providing protection > against insecure token storage on the client > > I agree with your reasoning - and that was more the intent of what I said. > We've seen refresh token

Re: [OAUTH-WG] Implementation questions around refresh token rotation

> Am 07.10.2020 um 09:20 schrieb Neil Madden : > >  > >>> On 6 Oct 2020, at 23:05, Aaron Parecki wrote: >>> >>  >> Hi all, I have a couple questions for those of you who have implemented >> refresh token rotation... >> >> Have you included the option of a grace period on refresh token

Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

> On 7. Oct 2020, at 19:45, Seán Kelleher wrote: > > Hi all, > > Long time lurker, first time poster, glad to be finally getting involved! > > In terms of weighing in on the revocation practice, I don't think this > document needs to address it as JWT ATs don't seem to require special >

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

-up preventions. I will start to work on an ID. > > Best regards, > Karsten > > On 29.08.2020 14:34, Torsten Lodderstedt wrote: >>> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen >>> >>> wrote: >>> >>> Hi all, >

Re: [OAUTH-WG] WGLC Review of PAR

l clients can choose an >> arbitrary redirect_uri without registering it. Once OIDC or FAPI is used, >> existing specifications require pre-registration of redirect URIs. I'm not >> sure but if PAR's "redirect_uri Management" is going to introduce rules that >>

Re: [OAUTH-WG] WGLC Review of PAR

yes. > On 3. Sep 2020, at 13:33, Brian Campbell wrote: > > Do you mean just putting the "Note:" back in front of it? WFM. > > > > On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt > wrote: > Thanks Brian! > > I suggest to put a Note:

Re: [OAUTH-WG] WGLC Review of PAR

ampbell [bcampb...@pingidentity.com] > Sent: Wednesday, September 2, 2020 3:41 PM > To: Justin Richer > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth > Subject: Re: [OAUTH-WG] WGLC Review of PAR > > Thanks Torsten, Taka, and Justin, > > I took the revised text from Justi

Re: [OAUTH-WG] third party applications

; third-party apps, it's proven to be useful in many other kinds of situations >> as well, even when it's a "first-party" app but the OAuth server is operated >> by a different organization than the APIs. I don't think the abstract needs >> any qualification on this and wo

Re: [OAUTH-WG] WGLC Review of PAR

ne which policies > should apply. > > — Justin > >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt >> wrote: >> >> >>> >>> >>> ¶6: Does the AS really have "the ability to authenticate and authorize >>> clients”?

Re: [OAUTH-WG] WGLC Review of PAR

x, or allowing only a query parameter to vary at > runtime. All of these can be enforced in PAR because the client is presenting > its authentication, as you point out, so the AS can determine which policies > should apply. > > — Justin > >>> On Aug

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen > wrote: > > Hi all, > > I think we all agree that proper countermeasures of mix-up attacks should > definitely be part of the BCP and 2.1 due to the severe impact successful > mix-up attacks have. > Theoretically speaking every

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

> On 11. Aug 2020, at 23:55, Brian Campbell > wrote: > > 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

Re: [OAUTH-WG] WGLC Review of PAR

> > > ¶6: Does the AS really have "the ability to authenticate and authorize > clients”? I think what we mean here is "the ability to authenticate clients > and validate client requests”, but I’m not positive of the intent. > > I think the intent is that the AS can check whether a

Re: [OAUTH-WG] WGLC Review of PAR

You are making a good point here. The reason we added the one time use constraint was the fact the client will include parameters supposed to be used only once, e.g. the PKCE code_challenge. For a traditional authorisation request, we would recommend the client to use a per transaction (== one

Re: [OAUTH-WG] third party applications

is still all internal, but it enables a separation of concerns. > ᐧ > > On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt > wrote: > In my experience OAuth is used in 1st party scenarios as means to separate > functions (e.g. central user management vs. different products) within

Re: [OAUTH-WG] third party applications

C 6749. > ᐧ > > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt > wrote: > I agree. OAuth works for 3rd as well as 1st parties as well. > > > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: > > > > Hi, > > > > Can "third-party&quo

Re: [OAUTH-WG] third party applications

I agree. OAuth works for 3rd as well as 1st parties as well. > On 28. Aug 2020, at 05:26, Dima Postnikov wrote: > > Hi, > > Can "third-party" term be removed from the specification? > > The standard and associated best practices apply to other applications that > act on behalf of a resource

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

ndpoint should be described in the > Privacy Considerations section. > >-- Mike > > From: OAuth On Behalf Of Dick Hardt > Sent: Wednesday, August 26, 2020 9:52 AM > To: Torsten Lodderstedt > Cc: last-c...@ietf.org; o

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09

Hi Roman, thanks for your review feedback. > On 21. Aug 2020, at 16:43, Roman Danyliw wrote: > > Hi! > > I conducted an another AD review of > draft-ietf-oauth-jwt-introspection-response-09. As background, -07 of this > document went to IESG Review and the document was brought back to

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

> On 25. Aug 2020, at 18:26, Denis wrote: > > Here is an additional comment: > > The text mentions in the Introduction: > >In example is a resource server using verified person data >to create certificates, which in turn are used to create qualified >electronic signatures. > >

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

Hi Denis, > On 25. Aug 2020, at 16:55, Denis wrote: thanks for the review and your feedback. > > > This draft contains a "Privacy considerations" section (Section 9). > . > The content of this section is as follows: > >The token introspection response can be used to transfer personal >

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

rk item of the Web Authorization Protocol WG of the IETF. > >Title : OAuth 2.0 Rich Authorization Requests > Authors : Torsten Lodderstedt > Justin Richer > Brian Campbell > Filename: draft

Re: [OAUTH-WG] Client authentication on token revocation

Hi Emond, I tend to agree with your assessment. Revoking bearer tokens without client authentication seems to be better than leaving the attacker the option to use them to invoke resources. However, if the attacker cannot use the access tokens (e.g. because they are sender constrained), the

Re: [OAUTH-WG] Namespacing "type" in RAR

Hi, the wording regarding type works for me. Similar to Brian, I don’t understand how the data type registry is supposed to work. In my opinion, type and locations are completely different from the other elements since they are required by the protocol itself. Their semantics must not be

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

hat model, the client doesn't have to mess with building URLs, 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 > &g

Re: [OAUTH-WG] Namespacing "type" in RAR

> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov wrote: > > > On 21/07/2020 18:43, Torsten Lodderstedt wrote: >> >>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov >>> wrote: >>> >>> >>> >>> On 21/07/2020 17:47, Ju

Re: [OAUTH-WG] Namespacing "type" in RAR

> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov wrote: > > > > On 21/07/2020 17:47, Justin Richer wrote: >>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov >>> wrote: >>> >>> On 18/07/2020 17:12, Justin Richer wrote: I think publishing supported “type” parameters isn’t a bad idea,

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

+1 > On 15. Jul 2020, at 21:37, John Bradley wrote: > > I support addoption > > On 7/15/2020 3:32 PM, Neil Madden wrote: >> I support adoption. >> >>> On 15 Jul 2020, at 18:42, Rifaat Shekh-Yusef >>> wrote: >>> >>>  >>> All, >>> >>> This is a call for adoption for the following OAuth

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> On 9. Jul 2020, at 19:58, Neil Madden wrote: > > The point is that RAR can’t make payment transactions the primary use-case, > emphasised throughout the draft, and then fail to even discuss this issue or > make any kind of suggestion as how to handle it. I’m still trying to understand

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> On 9. Jul 2020, at 19:28, Neil Madden wrote: > > On 9 Jul 2020, at 18:10, Torsten Lodderstedt wrote: >> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What in particular should the use conse

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

What in particular should the use consent with in this step? >>> >>> “FooPay would like to: >>> - initiate payments from your account (you will be asked to approve >>> each one)” >>> >>> The point is that a client that I don’t have any kind of

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> On 8. Jul 2020, at 23:52, Neil Madden wrote: > >> >> On 8 Jul 2020, at 20:56, Torsten Lodderstedt wrote: >> >>> Am 08.07.2020 um 20:46 schrieb Neil Madden : >>> >>> On 8 Jul 2020, at 19:03, Torsten Lodderstedt >>> wro

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> Am 08.07.2020 um 20:46 schrieb Neil Madden : > > On 8 Jul 2020, at 19:03, Torsten Lodderstedt > wrote: >>>> >>>> What in particular should the use consent with in this step? >>> >>> “FooPay would like to: >>> - initiat

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> On 8. Jul 2020, at 18:59, Neil Madden wrote: > > > >> On 8 Jul 2020, at 17:21, Torsten Lodderstedt wrote: >> >>  >> >>> On 8. Jul 2020, at 18:17, Neil Madden wrote: >>> >>>> On 8 Jul 2020, at 15:40, Justin Richer

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

> On 8. Jul 2020, at 18:17, Neil Madden wrote: > > On 8 Jul 2020, at 15:40, Justin Richer wrote: >> >> The two-phase approach is exactly what OBUK does, where you get one access >> token using client credentials before getting a more specific one in context >> of the user’s consent. This

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

Hi Neil, > On 8. Jul 2020, at 16:40, Justin Richer wrote: > > The two-phase approach is exactly what OBUK does, where you get one access > token using client credentials before getting a more specific one in context > of the user’s consent. This ends up being awkward to implement at best,

  1   2   3   4   5   6   7   8   9   10   >