Re: [OAUTH-WG] audience parameter in client_credentials

Hi Evert, The audience parameter isn’t standard- it was implemented before a standard modeling the corresponding concept (resource indicators) was introduced in https://www.rfc-editor.org/rfc/rfc8707.html. Audience is mostly an alias of the resource parameter, hence i wouldn’t be too worried about

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

On the SHOULD on top of S4. There are pretty common situations in which failing to get a response from an API is an acceptable outcome, and presenting an interactive prompt isn't. A classic example is a background update that the client can use to proactively fetch fresh data, that isn't critical

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

Sorry, my email client ate the first line of my reply, which was *Thanks Murray for the comments!* On Wed, Apr 12, 2023 at 11:11 PM Vittorio Bertocci wrote: > On the SHOULD on top of S4. There are pretty common situations in which > failing to get a response from an API is an acce

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

Ha, we chatted about this during yesterday's office hours meeting and I was chartered to propose new language, but I am not sure how to incorporate this new info. Let me try to summarize here and see your reactions, DW. Apps implemented in SPAs style can either handle token acquisition and renewal

Re: [OAUTH-WG] redirect uri and portals

In my experience the most common solution, adopted by many SDKs, is based on 2. Where you redirect after you concluded the token acquisition ceremony is a private consideration for your app, that shouldn’t interfere with how the client is registered. Oauth offers you the chance to store and

Re: [OAUTH-WG] [secdir] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

f in fact it is not needed, just > to annoy user > > (so, it is not due to incompatible policies, it is due to resource servers > intentional bad behavior). > > I think it’s worth to mention in the Security Considerations section, > > although I agree that the proble

Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12

Hi Robert, thanks for your comments! Some of the ideas you mention here were also touched upon during the AD review w Roman, the exchange we had might provide some context https://mailarchive.ietf.org/arch/msg/oauth/PBDCtVB7vtou5Dlz6nPJxX_5Yyo/ but more succinctly: - "step down". One of the key

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

Thanks for clarifying, I was indeed addressing the comment using DoS in its canonical meaning. The possibility of bad user experience is indeed present, and it is more general than just freshness: we do tackle that explicitly in the deployment considerations section. Did you have a chance to read

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

Thank you Valery for the review! The possibility of DOS is interesting. Here's the reasoning we followed when we opted not to mention it in the security considerations: - The client going back to the AS isn't a new thing introduced by the step up spec, given that it's the expected behavior for

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

Thanks Christer for your thorough review! A new draft ( https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-12.html) reflecting changes resulting from the feedback has been published. Comments inline On Thu, Feb 23, 2023 at 9:13 AM Christer Holmberg via Datatracker <

Re: [OAUTH-WG] AD review of draft-ietf-oauth-step-up-authn-challenge-08

make sense. I’ve snipped the below thread down to the open issues. > Bottom line, I think just a bit more explanatory text will help the reader > understand the framing concepts or push the responsibility to applications. > > > > Roman > > > > *From:* Vittorio Bertocci >

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

Wonderful, thanks Brock! On Thu, Jan 19, 2023 at 14:55 Brock Allen wrote: > *This message originated outside your organization.* > > -- > > The current version of Duende IdentityServer supports everything included > in this proposal, except for the new

Re: [OAUTH-WG] AD review of draft-ietf-oauth-step-up-authn-challenge-08

Thank you Roman for the super prompt and thorough review! We went ahead and published draft -10 incorporating your feedback and the changes described below. We are happy to make further changes as necessary, of course. Comments Inline >** The text uses the phrase "authentication level" a few

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

an Apache > HTTPd module implementing the OAuth 2.0 RS functionality, see: > https://github.com/zmartzone/mod_oauth2/blob/master/README.md > > Regards, > > Hans. > > > > > On Tue, Jan 3, 2023 at 6:51 PM Vittorio Bertocci 40auth0@dmarc.ietf.org> wrote: > >>

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Step-up Authentication Challenge Protocol

I am not aware of any IPR associated with this document. On Tue, Dec 20, 2022 at 5:14 AM Brian Campbell wrote: > *This message originated outside your organization.* > > -- > > I am not aware of any IPR associated with this document. > > On Tue, Dec 20, 2022 at 6:11

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Step-up Authentication Challenge Protocol

I am not aware of any IPR associated with this document. On Tue, Dec 20, 2022 at 5:14 AM Brian Campbell wrote: > *This message originated outside your organization.* > > -- > > I am not aware of any IPR associated with this document. > > On Tue, Dec 20, 2022 at 6:11

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

Thanks Takahiko, that's awesome! Thanks Rifaat, one more upcoming implementation: Steinar mentioned HelseID plans to implement this spec, see https://helseid.atlassian.net/wiki/spaces/HELSEID/pages/493256708/How+to+do+a+step-up+of+the+authentication+level+of+a+user#Step-up-for-APIs for details (I

Re: [OAUTH-WG] Step-up Auth: request acr as essential

rom >> kindly mentioning the standardized way which was defined 8 years ago. >> >> Taka >> >> 2022年11月3日(木) 22:04 Vittorio Bertocci : >> >>> Hi Takahiko, >>> thanks for the comment! >>> The use of the claims parameter for this use ca

Re: [OAUTH-WG] Step-up Auth: request acr as essential

Hi Takahiko, thanks for the comment! The use of the claims parameter for this use case is tricky. 1) if used as is, requesting a particular acr via claims isn't guaranteed to have any effect on the content of an access token, if an access token is even present: OIDC only defines the claims as

Re: [OAUTH-WG] WGLC for Step-up Authentication

tside your organization.* > > ------ > > Dear Vittorio Bertocci, Brian Campbell and Rifaat, > > > My sincere compliments to Vittorio and Brian for their persistent efforts > in making and improving the draft RFC and also for taking out valuable time > and efforts to reply to any quer

Re: [OAUTH-WG] WGLC for Step-up Authentication

Servers are able to disclose more information than >>>> strictly necessary about the authenticated user without the end user being >>>> able to know it. Such additional information may endanger the privacy >>>> of the user. >>>> >>>> Denis &

Re: [OAUTH-WG] WGLC for Step-up Authentication

Thanks Dima for the comment. Some thoughts: > (editorial)... Good point. "statically" would characterize the simplest of the scenarios, but in fact any case where the AS is the only arbiter of the authn level works for the point we are trying to make. We'll drop "statically". Thanks! > Apart

Re: [OAUTH-WG] WGLC for Step-up Authentication

Hi Pieter, thank you for your clarification and support! :) Cheers V. On Mon, Oct 10, 2022 at 7:52 AM Pieter Kasselman wrote: > *This message originated outside your organization.* > > -- > > I want to clarify that I don’t see any blockers to using the step-up auth >

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

I support adoption of this draft as a WG document. On Thu, Jul 28, 2022 at 5:17 PM Rifaat Shekh-Yusef wrote: > *This message originated outside your organization.* > > -- > > All, > > This is a call for adoption for the *SD-JWT* document >

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-step-up-authn-challenge-01.txt

a viable solution, and the need to step up (pun intended) the discussion so that we can incorporate your thoughts and contributions before we get too much instant legacy out there. Looking forward for the discussion at IETF114 On Mon, Jul 11, 2022 at 10:59 AM Vittorio Bertocci < vittorio.be

Re: [OAUTH-WG] Step-up Authentication review

" is always a superset of previous > authentication contexts and include authentication context history in the > access token to give visibility to the resource server on which > authentication contexts were satisfied when and how long ago (e.g. include > the latest acr and auth_time values as

Re: [OAUTH-WG] OAuth Redirection Attacks

The attack doesn't rely on redirecting to unregistered URLs, that's the problem. The goal of the attack is to circumvent phishing filters, by presenting a URL from a legitimate domain (the AS) that eventually redirects to the actual phishing URL. The actual phishing page doesn't need to target the

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

portunity to sanction behaviors that we > can’t distinguish from attacks. > > > > The prohibition on clients reusing an authorization code needs to remain. > > > > -- Mike > > > > *From:* Vittorio Bertocci

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I am a fan of this approach. It feels pretty empty to cast people out of compliance just because they are handling a realistic circumstance, such as network failures, that we know about beforehand. In addition, this gives us a chance to provide guidance on how to handle the situation, instead of

Re: [OAUTH-WG] self-issued access tokens

Hi Toshio, The scenario you describe is comparable to https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least in terms of validation logic. Please note that most of the validation software in common use today expects to work with just a handful of keys, typically one provider and

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Hi Denis, this aspect was debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there are many others) and the consensus reflected in the current text was clear. From: Denis Sent: Wednesday, April 14, 2021 1:19 AM To: Vittorio Bertocci

Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Thanks Martin for the comments and Benjamin for addressing some of them! Comments on the remaining ones: > (2.1) "...can use any signing algorithm." I presume there ought to be some > qualifiers on allowed algorithms? The algorithms referred to here are the ones defined by the usual

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Hi Francesca, Thanks for your review and thoughtful comments! Comments below. >1. - >[...] While it is reasonable to expect that a RS receiving an unencrypted token after requesting it to be encrypted will reject it, there are a number of cases where the RS might elect to do

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Hi Murray, Thank you for your comments! Answers inline > My co-AD pretty much nailed it. I would go further and say that her > comment >about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here. >SHOULD presents a choice; why might an implementer reasonably not do any

Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications

Hi Roberto, Thanks for the comments and apologies for the delay. Inline * An example with client_credential grant type would be nice too. Are you thinking of specific aspects that aren’t sufficiently clear from the text that would be clarified by one example? Unless there’s something

Re: [OAUTH-WG] About JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Hi Nikos, Thanks for looking into this! The profile aims at reflecting currently adopted practice as much as it is viable, and the overwhelming majority of the use cases involving access tokens today relies on bearer tokens. Note: although there's no practical difference between versions in the

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11

Thank you Joseph for your comments! > 1. (Editorial) What is the relationship between this document and RFC 7523. > They are using JWT for different purposes, but I think it would be useful to >clarify this in the introduction. Good point, I agree it would be good to preempt doubts on

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-access-token-jwt-11

Thank you Roni, Great catch! I made those two client_id values consistent, the change will appear in 12. Thanks V. On 2/7/21, 01:28, "Roni Even via Datatracker" wrote: Reviewer: Roni Even Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The

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

I get the scope right- that means that also code+PKCE+rotating RTs in JS would not be acceptable for your customers? From: Dominick Baier Date: Wednesday, February 17, 2021 at 00:27 To: Brian Campbell , Torsten Lodderstedt Cc: Vittorio Bertocci , "oauth@ietf.org" Subject: Re:

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

De Ryck Date: Sunday, February 14, 2021 at 22:45 To: Vittorio Bertocci Cc: Warren Parad , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) A couple of notes from my end: Developers building an application that consists of

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

. From: Warren Parad Date: Sunday, February 14, 2021 at 12:59 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) To restate, the TMI-BFF proposal is not trying to fix any of th

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

ures might be able to do more things in their app when using TMI-BFF than with JS code that relies on those AS capabilities to function. From: Warren Parad Date: Sunday, February 14, 2021 at 11:57 To: Vittorio Bertocci Cc: Stoycho Sleptsov , Neil Madden , oauth Subject: Re: [OAUTH-WG] Token

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

ks 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 Bertocci :

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

level driver. From: Warren Parad Date: Sunday, February 14, 2021 at 11:41 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) That only applies to third party cookies, it shouldn't af

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

Cc: Neil Madden , Vittorio Bertocci , oauth Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Correct it would never need to be used to authenticate a client, as a client is always offline and can directly use the backchannel. You would never need

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

tf.org" wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt >has been successfully submitted by Vittorio Bertocci and posted to the >IETF repository. > >Name: draft-bertocci-oauth2-tmi-bff >

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

ITP, for example From: Warren Parad Date: Sunday, February 14, 2021 at 04:54 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Can you expand on what silent authentication and ses

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

that risk drifting into insecure waters without it. From: Vittorio Bertocci Date: Sunday, February 14, 2021 at 04:27 To: Warren Parad , Neil Madden Cc: oauth Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hi Warren, thanks for the thoughtful

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

: Dominick Baier Date: Sunday, February 14, 2021 at 04:06 To: Vittorio Bertocci , Brian Campbell , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hi, Just making sure I understand - in your protocol flow diagram step D it l

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

situations. This answer was specifically on why having backend-issued tokens didn’t apply to this scenario. From: Warren Parad Date: Sunday, February 14, 2021 at 03:48 To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session I

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

=cookie, to AS to support domain first-party cookies and session management. Could you expand on how you envision this would work/solve the problems described above? From: Warren Parad Date: Sunday, February 14, 2021 at 01:51 To: Neil Madden Cc: Vittorio Bertocci , oauth Subject: Re: [OAUTH-WG

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

on behalf of Neil Madden Date: Sunday, February 14, 2021 at 00:17 To: Vittorio Bertocci Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) I have a lot of security concerns about this draft. The draft alludes to secur

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

ho. На пт, 12 фев 2021 г., 22:46 Vittorio Bertocci mailto:40auth0@dmarc.ietf.org>> написа: Dear all, Brian and yours truly are proposing a new specification that shows how the user agent frontend of a web app can delegate token acquisition and persistence to its backend, and reques

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

forward for your feedback! B On 2/12/21, 12:41, "internet-dra...@ietf.org" wrote: A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt has been successfully submitted by Vittorio Bertocci and posted to the IETF repository. Name: draft-berto

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10

, I didn't appreciate this was awaiting on a response. > -Original Message- > From: Vittorio Bertocci > Sent: Thursday, November 19, 2020 3:45 AM > To: Roman Danyliw ; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-

[OAUTH-WG] November Interim meeting on WebID/IsLoggedIn followup

Dear all, This is a followup on the actions we agreed upon during the November interim meeting in November (notes in https://datatracker.ietf.org/meeting/interim-2020-oauth-12/materials/minutes-interim-2020-oauth-12-202011021200-00). Apologies for the delay. The TL;DR is that we decided it

[OAUTH-WG] Detailed review of OAuth2.1

Dear authors, It took ages but I finally managed to go thru a full review of the current OAuth2.1 draft. Apologies for the delay. Metacomments: * The VAST majority of the comments are suggestions for improving clarity, mostly on historical language coming from 2.0 that I found myself

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-access-token-jwt-10

Thank you Roman for the thorough review! I applied all the editorial and typo fixes. I have a few questions on some comments, once solved I'll update accordingly and push a new version. Thanks! Inline >On 11/15/20, 08:39, "OAuth on behalf of Roman Danyliw" wrote: >[..] >** Section

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

Hey Aaron, Auth0 does offer a configurable grace period, during which the “preceding” token can be reused. I am not 100% sure what we do in the exact scenario you described, and I will double check for you, but here’s my intuition. The operation redeem(RT_n) should result in AT, RT_n+1.

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

Hi Andrii, Thanks for the thoughtful comments! Here’s my 2 c. On the proposed language: given that the JWT AT profile is just providing more details on the content of an AT, making JWT ATs a proper subset of all ATs, readers should have no reason to believe that introspection or any other

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

Thanks for the clarification! I agree, the scenarios you described would be improved by actually killing the ability of the app to access the resources, instead on relying on the client to discard the tokens without leaking them. That's why I am a big proponent of the online_access scope, tho I

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

Thanks for bringing the revocation topic up. In brief: * I agree on the comments that differentiate between userinfo and introspection- userinfo doesn’t really play a role in validation hence I’d keep it out of the JWT AT doc. * I agree that the introspection endpoint shouldn’t

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

Hey Jim, regarding > Every logout event should trigger token revocation That isn’t necessarily the case. An access token represents the ability of a client to access a given resource; the fact that it requires an authentication transaction/session establishment to be issued to the client does

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

l Cc: Vittorio Bertocci , "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question If I understand "The intent would be to present that information in the same way you would when querying a users/, encoded in claims" correctly, the "roles

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

Thanks to both! I agree this can use more clarity. I am modifying the figure as in the following, adopting a style closer to 6.1 of 7519 and providing a more descriptive caption. Header: {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"} Claims: { "iss":

[OAUTH-WG] New podcast on identity specifications

Dear all, This is an informal mail to inform you that there’s a new podcast, identityunlocked.com, dedicated to inform and explain new identity specs developments for developers. You can find a more detailed explanation of the

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

Hi Logan, Thanks for the note. The intent would be to present that information in the same way you would when querying a users/, encoded in claims; hence groups would be a list of values representing what groups the subject belongs to, rather than a list of full group definitions (with all the

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

ke a difference if those keys are all published in an indifferentiated list. From: Hannes Tschofenig Date: Thursday, September 17, 2020 at 03:23 To: Vittorio Bertocci , "oauth@ietf.org" Subject: RE: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07 Hi Vittorio, Thanks for the

Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens: IPR Confirmation

Hi Hannes, Thank you! I am not aware of any IPR related to https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/. On 9/17/20, 05:48, "Hannes Tschofenig" wrote: Hi Vittorio, I am working on the shepherd writeup for the "JSON Web Token (JWT) Profile for OAuth 2.0

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

Thank you Hannes for the thorough review, and thanks in advance for the writeup! I applied most of the changes you suggested, and submitted a new draft. Comments on questions and suggestions I didn’t understand below: * Question: If you refer to RFC 6750 and then list the steps are you just

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

Thanks Hannes! I will go thru the comments and update accordingly by EoW. From: OAuth On Behalf Of Hannes Tschofenig Sent: Monday, September 7, 2020 11:30 PM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07 Hi Victorio, Hi all, I am doing my shepherd

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

+1 From: OAuth On Behalf Of Dick Hardt Sent: Wednesday, July 15, 2020 10:55 AM To: Rifaat Shekh-Yusef Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document +1 On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com> > wrote: All,

Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

> logout at the authorization server One important detail here is that if the refresh token has been obtained by including the scope "offline_access", then its lifetime should not be tied to the lifetime of the session (see https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess),

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

Denis, the change you mentioned is basically a typo, which I did fix but did not publish a new draft for- that doesn’t change the substance of the consensus (and is something that will be fixed in the subsequent phases of the process). Whether the sub should be mandatory has been discussed for two

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

To: Vittorio Bertocci Cc: Denis , Benjamin Kaduk , "oa...@ietf..org" Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Hi Vittorio, Yeah, this does make a bit of sense. So, the goal is to guide implementors from making bad choices,

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

principle than about concrete scenarios, expressive power or security. From: Jared Jennings Date: Monday, May 11, 2020 at 06:30 To: Denis Cc: Benjamin Kaduk , Vittorio Bertocci , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Acces

Re: [OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding state into the JWT

Hi Prabath, Thanks for your comment! Here are my thoughts. I don’t believe embedding the state in the AT would help. The state is generated (hence verified, if used for protection) by the client, but the content of the AT is really meant for the RS, which has no direct knowledge of what the

Re: [OAUTH-WG] JWT profile and IdentityServer

Thank you Dominick, very useful! I’d like to understand more about the security risks you mention. My goal is not to change your mind on the implementatio, just to make sure I better understand the general implication. >* the user info endpoint needs to do extra checking This is an interesting

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

Thanks Denis for the thorough commentary. > The title of this spec. Fixed, thanks! > The client MUST NOT inspect the content of the access token This is really a sticky point. I really want to acknowledge your PoV on this, but at the same time I found this to be one of the biggest sources of

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

work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Author : Vittorio Bertocci Filename: draft-ietf-oauth-access-token-jwt-07.txt Pages : 19

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

Thanks Brian, that appears to have worked! From: OAuth on behalf of Brian Campbell Date: Monday, April 27, 2020 at 06:26 To: Vittorio Bertocci Cc: oauth Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" This old thr

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

Kaduk" wrote: Just on the xml2rfc bits... On Wed, Apr 22, 2020 at 07:26:40AM +, Vittorio Bertocci wrote: > > > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 of this doc. > Oh wow. That’s a feature of XML2RFC,… my source

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

Date: Friday, April 24, 2020 at 15:49 To: Vittorio Bertocci Cc: oauth , Vittorio Bertocci Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Dear Vittorio, I apologize. To me, the requirements on "aud" and "sub" soun

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

hiko Kawasaki Date: Thursday, April 23, 2020 at 18:01 To: oauth Cc: Vittorio Bertocci Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" I apologize if my previous post has made you all here feel unpleasant, especially I'm sorry for the auth

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

igh, you’re right. I was planning to add those eventually, I guess the time has come. From: Mike Jones Date: Tuesday, April 21, 2020 at 11:07 To: oauth , Vittorio Bertocci Cc: Rifaat Shekh-Yusef Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

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

Ouch! Sorry  fixed From: Dominick Baier Date: Tuesday, April 21, 2020 at 10:23 To: oauth , Rifaat Shekh-Yusef , Vittorio Bertocci Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Oh and while we are at it - could you also fix the

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

This is a great point. In my head I just considered the OIDC semantic and thought only of highlighting the app identity case, but you are absolutely right that not mentioning the user case at all is confusing. I added the language you suggested at the beginning of the sub definition. Thanks!

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

Thanks guys for the commentary here. I wasn’t too partial on the “time claim” type. I just went for “Iat” very much in line with Vladimir’s guess, it was quite empirical: * it comes from OIDC, and for the usual consideration that existing logic used for processing ID_tokens will be

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

Thanks for the catch! Will add a mention of that in section 2.1 as well. From: OAuth On Behalf Of Brian Campbell Sent: Thursday, April 16, 2020 1:16 PM To: Aaron Parecki Cc: oauth Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" I'll +1

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

Thanks Dominick for your comments! Inline > All other OAuth specs make a very clear distinction between users and client. There’s a nuance worth highlighting here: sub != user. In previous discussions on this topic it has been brought up that the JWT spec defines sub as identifying the

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

about this, we can complement the warning in the privacy considerations in draft-06 to highlight this scenario- but honestly that seems overkill to me :) Thanks V. From: "Manger, James" Date: Wednesday, April 15, 2020 at 00:37 To: Vittorio Bertocci , George Fletcher , Denis , "

[OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-access-token-jwt-06.txt

version of I-D, draft-ietf-oauth-access-token-jwt-06.txt has been successfully submitted by Vittorio Bertocci and posted to the IETF repository. Name: draft-ietf-oauth-access-token-jwt Revision: 06 Title: JSON Web To

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

Thanks George, you described exactly what I was thinking. I agree with your conclusions throughout the thread. Now that we have JTI mandatory, preventing tracking intra-API could be achieved only by issuing a new token for every transaction regardless of the presence of a sub, and a sub whose

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

by design. On Mon, Apr 13, 2020 at 18:05 Dick Hardt wrote: > > > > An SDK is going to support "sub" wether it is required or optional. > > > > On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci > wrote: > >> “Ide rockers” is iPhone autocorrect jargon fo

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

“Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci wrote: > It’s certainly possible to conceive ATs without subs, but I think the > profile would be way less useful for SDK developers. > On the objections: > The

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

It’s certainly possible to conceive ATs without subs, but I think the profile would be way less useful for SDK developers. On the objections: The sub doesn’t have to be a user, if you look at the earlier discussions the case in which the token has been issued for an application via client creds

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

Hi Denis, Thank you for your feedback! Inline > Privacy has not really been a concern in the WG since originally the AT and > the RS were co-located. Colocation of AS and RS was a frequent occurrence, but by no mean mandatory… AFAIK one of the drivers for the changes between OAuth1 and OAuth2

[OAUTH-WG] oauth-browser-based-apps-05 - BFF

Hey Aaron, Thanks for today’s update on oauth-browser-based-apps, very useful. As agreed, here’s the summary of the point mentioned during today’s call. 1. The last paragraph of 6.2 mentions that an access token could be used as session between the JS frontend and its backend, but no details

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

es not apply. It may seem innocuous to require these deployments to explicitly include a broad audience like "api.example.com" anyway, that can lead to implementers ignoring the requirement (leading to interop issues), not validating it (also leading to interop issues or securi

Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens

Hi Karl, Thanks for the comment. I agree that having a framework for further clarifying authentication assurance would allow SDK owner to provide even more functionality out of the box. I also agree that the definition of such a framework for authentication assurance goes beyond the scope of

  1   2   >