[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-v2-1-11.txt

2-1/issues > > > > > > Aaron > > > > > > > On Tue, May 14, 2024 at 5:14 PM wrote: > > > > > Internet-Draft draft-ietf-oauth-v2-1-11.txt is now available. It is a > > > > > work > > > > > item of the Web Authoriz

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

Your proposal sounds good to me. Am 28. Dez. 2023, 10:25 +0100 schrieb Daniel Fett : > Hi Roman, > thanks for the detailed review and your valuable feedback! > I think you raise one important point in particular that I'd like to discuss > on the list: > Am 19.12.23 um 00:08 schrieb Roman

Re: [OAUTH-WG] Relationship between SPICE and OAuth

oup document you have relinquished control to the group. While > your opinion is important, it has the same weight as the opinion of any other > working group participant. The theme is "We reject: kings, presidents, and > voting. We believe in: rough consen

Re: [OAUTH-WG] Implementation Status of the "OAuth 2.0 Security BCP"

Hi, the yes open banking ecosystem was implemented based on the Security BCP. best regards, Torsten. Am 4. Okt. 2023, 16:46 +0200 schrieb Tschofenig, Hannes : > Hi all, > > as part of the shepherd write-up for the "OAuth 2.0 Security BCP" document, > we are looking

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

> > > > John, I also need your confirmation! > > > > Von: OAuth Im Auftrag von Tschofenig, Hannes > > Gesendet: Mittwoch, 4. Oktober 2023 15:41 > > An: oauth@ietf.org > > Betreff: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current > &g

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

+1 for adoption Am 30. Sept. 2023, 15:33 +0200 schrieb Aaron Parecki : > I support adoption > > > > On Sat, Sep 30, 2023 at 5:53 AM Rifaat Shekh-Yusef > > wrote: > > > All, > > > > > > This is an official call for adoption for the JWT and CWT Status List > > > draft: > > >

Re: [OAUTH-WG] OAuth and JWT/VC documents

Hi Orie, best regards, Torsten. Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele : > Torsten, > > Thanks for sharing this excellent framing. > > I agree with everything you said. > > Please correct me if I'm wrong about anything in this summary: > > 1. Keep work

Re: [OAUTH-WG] OAuth and JWT/VC documents

-established relationship. Also, in a wallet world, we see the need to allow an app on the phone to securely authenticate towards an AS, which requires key bound assertions. draft-ietf-oauth-attestation-based-client-auth is our proposal to cope with those issues. best regards, Torsten. Am 8. Sept

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

+1 for adoption Am 30. Juli 2023, 16:28 +0200 schrieb Orie Steele : > I support adoption. > > > On Sun, Jul 30, 2023, 9:15 AM Pieter Kasselman > > wrote: > > > I support adoption of this draft. > > > > > > From: OAuth On Behalf Of Rifaat Shekh-Yusef > > > Sent: Saturday, July 29, 2023 8:25 PM >

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

+1 for adoption Am 30. Juli 2023, 16:28 +0200 schrieb Orie Steele : > I support adoption > > > On Sun, Jul 30, 2023, 9:14 AM Pieter Kasselman > > wrote: > > > I support adoption. > > > > > > From: OAuth On Behalf Of Rifaat Shekh-Yusef > > > Sent: Saturday, July 29, 2023 8:27 PM > > > To: oauth

Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication

Those claims are asserted by the issuer of the assertion, which could be a trusted third party. Trust management happens on top of the draft. This could mean x5c, could also be a trust list with the issuer URLs. In the OID4VC High Assurance Profile, which utilizes this draft, we will facilitate

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

. best regards, Torsten. Am 13. Juni 2023, 13:13 +0200 schrieb Oliva Fernandez, Jorge : > Ok thanks, > > And in the response of the /token endpoint should be inside the > “authorization_details” as described in the section 7? > > Best regards. > > From: OAuth on behalf of

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

Am 13. Juni 2023, 12:02 +0200 schrieb Oliva Fernandez, Jorge : Hi Torsten, Thanks for your answer but this seems still very confused to me, so just let me put a real use case for RAR and see if I can understand correctly, suppose that Open Banking (never mind the country) replace

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

: there is no issue with the examples. Section 9 just shows one way to implement it, you could use other ways. best regards, Torsten. Am 12. Juni 2023, 19:22 +0200 schrieb Brian Campbell : > I think Torsten did the example with "debtorAccount" so he can maybe provide > more insi

Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification

I support adoption of this draft. It is an important piece to use SD-JWT for Verifiable Credentials. Am 27. Mai 2023, 12:52 +0200 schrieb Leif Johansson : > Likewise! > > Skickat från min iPhone > > > 27 maj 2023 kl. 01:12 skrev Giuseppe De Marco : > > > > Hi, > > > > I support sd-jwt-vc with the

Re: [OAUTH-WG] OAuth 2.0 Proof-of-Possession (PoP) Security Architecture

there is anything missing? best regards, Torsten. Am 27. März 2023, 13:48 +0900 schrieb Nat Sakimura : > Hi Rifaat, > > Here is my slides on the OAuth 2.0 Proof-of-Possession (PoP) Security > Architecture discussion. > Sorry for being so late in delivering it! > > B

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 9

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

be leveraged in other OAuth applications. This is a continuation of the session Kristian and Tobias held at the last meeting. 20 min would be much appreciated. best regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

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

ST properly sanitized and handle the data passed in the authorization_details in order to prevent injection attacks.“ https://author-tools.ietf.org/iddiff?difftype=--hwdiff=draft-ietf-oauth-rar-21.txt best regards, Torsten. > > Regards, > Rob > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

OMMENTS > > ### Section 1 > > I like the use of EUR rather than USD ;-) :-) > > Suggest to also add "bic" in addition to "iban" to be consistent with > https://en.wikipedia.org/wiki/Single_Euro_Payments_Area added bic the example (even though it’s not re

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

oose the format and representation of the data. It is not required to use the authorization details structure, it can transform and filter it. > > In Section 7.1, I can't understand what's meant by "This mechanic ...". Changed it to „This example“. best regards, Torsten. > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

n_details parameter". done I published a new revision with all changes https://www.ietf.org/archive/id/draft-ietf-oauth-rar-16.html <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-16.html> best regards, Torsten. > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

Hi Roman, I just published revision -14 with the all the agreed changes. https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html best regards, Torsten. > Am 24.10.2022 um 13:07 schrieb Roman Danyliw : > > Hi Torsten! > > Thanks for the response. More inline ... >

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

ment_initiator" type with the API URL prepended. > > ** Section 7.1. Typo. s/sub set/subset/ > > ** Section 8. What is the difference between this section and Section 5 > beyond this text explicitly stating the name of the error value > (invalid_authorization_detail

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

regards, Torsten. > Am 19.08.2022 um 16:23 schrieb Jaimandeep Singh > : > > Hi Karsten, > > Thx a lot for all the time and effort in explaining the things. This brings > up an important discussion point as we are revising OAuth 2.0. Do we need to > make the author

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, J

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

> Am 02.08.2022 um 19:30 schrieb David Chadwick > : > >  > Hi Torsten > > your use case sounds like an online use case, not an offline one. So its a > question of balancing a long lived SD-JWT along with a revocation mechanism > vs a short lived minimal JWT

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

://cloudsignatureconsortium.org/resources/ <https://cloudsignatureconsortium.org/resources/>). OpenID Foundation’s FAPI working group added RAR support to the FAPI 2 baseline profile (https://openid.net/specs/fapi-2_0-baseline-01.html <https://openid.net/specs/fapi-2_0-baseline-01.html>). best regards, Tor

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

nce on > when to use what mechanism would be good and how credential types influence > the deployment. Does this work? „The later does not require application level encryption but it requires another message exchange between client and AS. „ > > The following paragraph makes me wonde

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

covery and trust among the parties. In the next step, we want to build a Proof of Concept to evaluate and demonstrate the feasibility of the approach. If you want to know more or want to contribute just drop me an email. best regards, Torsten. ___

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

• added privacy considerations re authorization details in token response Thanks to all the reviewers! best regards, Torsten. > Am 12.09.2021 um 17:31 schrieb internet-dra...@ietf.org: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directorie

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. >

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

d even if considered sensitive as long as there is a reasonable purpose and a legal basis. best regards, Torsten. > Am 06.09.2021 um 09:52 schrieb Jacob Ideskog : > > Yes, privacy considerations could be more explicit about this. It should > probably explicitly mention the token respo

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)

pposed to change the security assumptions of a spec. It is supposed to fix typos and clarify ambiguities. Changing the security assumptions or applying other normative changes is subject to new RFCs replacing the older ones. So from my perspective, your inquiry exceeds the scope of an

Re: [OAUTH-WG] RAR WGLC comment

Hi all, I created a PR for this change. https://github.com/oauthstuff/draft-oauth-rar/pull/76 <https://github.com/oauthstuff/draft-oauth-rar/pull/76> Please review and comment/approve. best regards, Torsten. > Am 19.06.2021 um 17:01 schrieb Filip Skokan : > > I supp

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

ving the AS be required > to fill in the account identifiers in the token response could be > restrictive. I think this kind of enrichment is nice, but I suggest that it > be made clear that it is optional. Rephrased it to clearly point out this is _a_ design option. > > Section 12 >

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

. This means RAR on one hand and scopes + resource indicators on the other hand are clearly decoupled and independent. best regards, Torsten. > Am 18.06.2021 um 20:13 schrieb Brian Campbell > : > >  > In my reading and understanding of the text and intent, the content and > meani

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

shed Authorization Requests (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par) extension that works similarly. We indeed have done a security analysis of this draft. BTW: the communication between user agent and authorisation server is still not protected with mTLS in the solution you de

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

feedback. The draft is now feature complete from the perspective of the authors. So we are aiming at asking the chairs to start WGLC. best regards, Torsten. > Anfang der weitergeleiteten Nachricht: > > Von: internet-dra...@ietf.org > Betreff: New Version Notification for draft-ie

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 Rif

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

comparison could be performed in this context. Please give us feedback on the PR to drive the discussion. best regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

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)

Hi Vittorio, thanks for the explanation. Do you assume the frontend passes the code or initial refresh token to the backend using an application specific mechanism? Why isn’t this part of the bff-token request? best regards, Torsten. > Am 14.02.2021 um 20:19 schrieb Vittorio Berto

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

code grant type. I would have expected to frontend to pass an authorisation code to the bff-token request. But section 4.1. only defines the parameters „resource" and „scope" for the bff-token endpoint. thanks, Torsten. > Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci >

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

Hi Andrii, > Am 07.02.2021 um 21:30 schrieb Andrii Deinega : > >  > Hi Torsten, > > thank you for your response. > > My use case is pretty straight forward > > An OAuth client queries the AS to determine the active state of an access > token and gets

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

recommendation to use PAR to cope with large requests and for request protection Your feedback is highly appreciated. best regards, Torsten. > Am 07.02.2021 um 13:42 schrieb internet-dra...@ietf.org: > > > A New Internet-Draft is available from the on-line Internet-Drafts &

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

the introspection response data and wants the AS to take liability re the data quality. I’m not sure whether there are similar use cases if a client introspects a refresh token. What is your use case? best regards, Torsten. > Am 07.02.2021 um 08:41 schrieb Andrii Deinega : > > Hi WG, >

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?

URI will help. >> >> I don't know that that's needed either. But do have some text to suggest >> that you think would be helpful? >> >> >> >> Vladimir >> >> On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote: >>>

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

to the AS? best regards, Torsten. > Am 12.12.2020 um 08:26 schrieb Neil Madden : > >  > Not directly related to DPoP or OAuth, but I wrote some notes to help > recovering XSS Nihilists: > https://neilmadden.blog/2020/12/10/xss-doesnt-have-to-be-game-over/ > > — Neil > &

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

counter measure is the inclusion of the endpoint URL and HTTP method in the proof, since it reduces the attack surface to a particular URL. So in the context of freshness, we are talking about using the same proof with the same URL again. best regards, Torsten. > Am 03.12.2020 um 10:20 schr

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

to treat errors related to the redirect 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 redirection URI." I think if an implementor ignores th

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

processing of unknown authorization details parameters • clarified dependencies between resource and authorization_details parameters • Updated references to current revisions or RFC numbers best regards, Torsten. > Begin forwarded message: > > From: internet-dra...

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

reference to privacy considerations to section 5 * added text in privacy considerations regarding client/user tracking Thanks for the review comments and change proposals. best regards, Torsten. > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: [OAUTH-WG

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

hotspot and retries). We did not implement a grace period for the same reason. Refresh token rotation is a countermeasure against refresh token theft and replay for public client. A grace period to some degree limits it effectiveness against exactly this attack. best regards, Torsten. &g

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

Thanks to all. I incorporated the text into the upcoming next revision of the draft. > On 3. Sep 2020, at 14:14, Dave Tonge wrote: > > Looks really good to me, thanks Brian. > > On Wed, 2 Sep 2020 at 21:42, Brian Campbell > wrote: > Thanks Torsten, Taka, and Justin, &g

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

s that the AS can check whether a client is authorized to > make a particular authorization request (specific scopes, response type, > etc.). But checking authorization to request authorization is confusing > wording. I think your working is less confusing and still allows for the > int

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

it isn't one of those? Every implementation is also free to use their own specific claims. This is defined in section 2.2. of RFC > > ** Section 5. Per " The AS MUST ensure the release of any privacy-sensitive > data is legally based", recommend also i

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. > >

  1   2   3   4   5   6   7   8   9   10   >