Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

ohn B. > On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote: > > Hi Vittorio, > > The text you quoted is copied form the abstract of the draft itself. > > > *Authors,* > > Should the draft be updated to cover the logical identifier case? > > Regards, > Rifaat > > &

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

that no changes are needed to > draft-ietf-oauth-resource-indicators, as the logical audience work is > already happening in another draft. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * John Bradley > *Sent:*

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

rameter that Microsoft is using? > On 1/20/2019 3:59 PM, Vittorio Bertocci wrote: > > First of all, it wasn't my intent to disrupt the established process. In > my former position I wasn't monitoring those discussions hence I didn't > have a chance to offer feedback. When I saw

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

efore, I do think that's within the bounds of the draft's >> definition of 'resource' as a URI. And that perhaps all that's needed is >> some minor adjustment and/or augmentation of some text to make it more >> clear. >> >> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Berto

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

. On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef wrote: > Thank you guys! > > > On Monday, January 21, 2019, Vittorio Bertocci wrote: > >> Hi Rifaat, >> absolutely. Brian and myself already started working on some language, >> however this week he is in vaca

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

that separate from the logical resource that may span > more than one RS endpoint. > > Merging the two and we are probably back at the AS looking into the URI to > figure out which one it is. I think that is harder for implementations and > more likely to have security issues down th

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

Hi Rifaat, one detail. The tech summary says An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the *location* of the protected resource(s) to which it is requesting access. But at least in

Re: [OAUTH-WG] expires_in

It does sound like a best practice and nearly all the providers I've ever worked with do have an expiration for ATs, however there are counterexamples (most notably, dropbox ) and they seem to be doing fine so far. Do we know anyone on

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all, Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative. I have a number of customers that are reacting

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

use implicit for today Thx V. On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt wrote: > > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci < > vittorio.berto...@auth0.com>: > > Hey Torsten/Tomek, > Can I ask a clarification on the below? > Torsten, you men

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hey Torsten/Tomek, Can I ask a clarification on the below? Torsten, you mentioned that an AS doesn't need to issue a RT- the browser code can just repeat an authorization request. Did I get it right? But in order to preserve the user experience, that cannot really happen as a full page redirect;

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

As mentioned during IIW when this pattern was borught up: I think readers should receive a stronger warning about the known challenges of that approach. Namely, assuming that the developer wants to perform API calls from the browser: - Making the app backend the true client for the AS is

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> There are indeed several ASs which, possibly because of an interpretation of OIDC, assume refresh tokens mean offline access and are mutually exclusive with public clients. AFAIK both Microsoft and Google do support RTs with public clients, but their lifecycle is independent from the session

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

rsten Lodderstedt wrote: > Hi Vittorio, > > > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : > > > > Thank you! > > On the RT, more questions: > > > > - where would you save the RT? Iam thinking of the no-backend case in > particular. There’s a lot o

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Sat, Dec 8, 2018 at 5:12 AM Torsten Lodderstedt wrote: > Hi Vittorio, > > > Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci : > > > > Thank you Torsten. > > I think that a lot of the considerations below need to be tempered with > concrete considerations about the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

at least handle it, I am not sure I understand the pushback on providing that level of clarity. On Sun, Dec 9, 2018 at 12:57 AM David Waite wrote: > > > On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci < > Vittorio=40auth0@dmarc.ietf.org> wrote: > > > Can you give a c

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

. > > > > cheers > > Dominick > > > > On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote: > > Hi Vittorio, > > > > Thanks for the good starting point of standardizing JWT-ized AT. > > > > One feedback. > > The “sub

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

02.html* > <https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html> ? > - Should we mention the "act" claim defined by Token Exchange as a > possible claim for JWT access tokens? > - any reason to rely on RFC 7662 (Introspection) for the token format? I > see that the

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> Thanks for the good starting point of standardizing JWT-ized AT. >>> >>> One feedback. >>> The “sub” claim can include 2 types of identifier, end-

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

better interoperability. > > Dave > > On Tue, 26 Mar 2019 at 17:48, Vittorio Bertocci 40auth0@dmarc.ietf.org> wrote: > >> thank you Steinar and everyone else for the comments on this! >> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >> Be

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

t; On 26. Mar 2019, at 17:48, Vittorio Bertocci 40auth0@dmarc.ietf.org> wrote: > > > > thank you Steinar and everyone else for the comments on this! > > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. M

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

, I’m concerning user & client ids collision. >> I haven’t seen such implementations, but user-select username as sub, or >> incremental integer as sub & client_id will be easily collide. >> >> If you can enforce collision resistant IDs between user & client >> insta

Re: [OAUTH-WG] JWT ATs and authenticated encryption

Hi Neil, thanks! This does sound very interesting. Just to clarify, you would document this in a separate doc extending JOSE? We could then mention it from the JWT AT profile, whihc would remain lightweight and implementation independent. thanks V. On Tue, Mar 26, 2019 at 3:11 AM Neil Madden

[OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Dear all, I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

r can be challenged for additional >> credentials or required to re-authenticate due to a number of different >> reasons. For example, OIDC prompt=login or max_age=NNN. In this context, >> I'd assume that the auth_time value should be updated to the latest time at >> which

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

and with whatever protections we can put in place, as opposed to leave developers to their own device. On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell wrote: > A few remarks/responses inline below this time... > > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci 40auth0@dmarc.ietf.org>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

e (e.g. urn:x-mydomain:apis). Which > is perfectly legal but maybe not in the spirit of the spec:) I am receiving > feedback from developers that binding access tokens narrowly to the > resource where they will be presented is concerning from a chattiness > perspective (latency

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

sing off the shelf software components. On Thu, Apr 4, 2019 at 7:14 AM George Fletcher wrote: > Comments inline... > > On 4/3/19 3:38 PM, Vittorio Bertocci wrote: > > Thanks guys for the comment, sorry for the delay in addressing them. > I am not married to the claim

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

y API scenario I described earlier: if an AT is all you are getting , it seems you should be able to get any info you could have gotten otherwise. On Thu, Apr 4, 2019 at 10:40 AM Schanzenbach, Martin < martin.schanzenb...@aisec.fraunhofer.de> wrote: > Hi Vittorio, > > >

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

pact on adoption & expectations of successful interop. I agree that the “why” remains the highest order bit, and as you mentioned we have seen good arguments. On Sat, Mar 30, 2019 at 02:15 Benjamin Kaduk wrote: > Hi Vittorio, > > On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittor

Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02

To add some color, here there's a concrete scenario where many of those concepts come together (or collide, if you prefer). Azure AD implements am early draft of token exchange, largely for implementing a cloud friendly version of kerberos constrained delegation- say a native client calls a mid

Re: [OAUTH-WG] popular apps that use appauth?

Ahh, as John knows this is a big pet peeve for me :) Although that's all true on mobile, on desktop things are more complicated. - Using a system browser on the desktop (Linux/Mac/Windows) means that you don't control the experience (there might be modal dialogs occluding the browser or

Re: [OAUTH-WG] popular apps that use appauth?

Baier wrote: > A good example of a desktop application using browser authentication is > Github for Desktop. > > They use custom URLs/callbacks for both OSX and Windows. Works very well. > > ——— > Dominick > > On 25. February 2019 at 11:48:20, Vittorio Be

Re: [OAUTH-WG] popular apps that use appauth?

; > https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.Web > > I have encouraged Apple to provide a SSO service on OSX. > > The availability of WebAuthn in browsers may make the platforms rethink > some things. > > John B. > > > On Mon, Feb 25

[OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

Hi all, during today's office hours call I pointed out that oauth-mtls-13's abstract only mentions access token, although the spec does provide (some) guidance on refresh token binding as well. Although in the end implementers would do the right thing, given that they have to read the spec in its

Re: [OAUTH-WG] OAuth WG Sessions in Montreal

I will publish an update of the JWT profile for ATs by then. If there is a slot available, I would love to discuss it. I will attend in person this time. On Mon, May 27, 2019 at 2:04 PM Rifaat Shekh-Yusef wrote: > All, > > Please, let us know if you have any topics that you would like to

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

sub" > effectively == "client_id". We don't need to push that logic to the RS. > >> Vladimir > >> > >> On 07/05/2019 12:16, Neil Madden wrote: > >>> Ah, that makes sense. Well, we already add a grant_type claim to our > JWT-based access tokens, so

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

; On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci > wrote: > >> For many of the products I have been and I am working on, sub and >> client_id can't be arbitrarily changed - the examples I provided aren't >> hypothetical: in my research *all *the providers adding sub in

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

t; > Hans. > > On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci > wrote: > >> Let me try a different angle. An AS might generate sub claims and >> client_id identifiers using a different format/template. That means that >> there might be a client with client_id X tha

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I am not following, Vladimir. What do you mean? Can you make some examples to clarify? The userinfo is always colocated with the AS, hence I would expect most vendors not to use JWT for the ATs issued for userinfo access On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov wrote: > >

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

ttps://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >> >> -Karl >> >> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >> Vittorio=40auth0@dmarc.ietf.org> wrote: >> >> *This message originated outside your organization.* >>

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Fair enough! What others think about it? Exploring the approach: would we want a bool claim or an enumeration, e.g. sub_type = [ resource_owner | client ] ? On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov wrote: > Hi Vittorio, > > On 06/05/2019 22:22, Vittorio Bertocci wrote: >

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

: > the scope and way of generating sub/client_id is orthogonal to the > semantics IMHO but if I'm the only one who thinks so, I'll rest my case > > Hans. > > On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci > wrote: > >> See below, Hans- the sub doesn’t have to be

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

ted ad-hoc for that particular RS. Would you prefer to have a dedicated claim that distinguish between user and app tokens rather than reusing grant_type? On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov wrote: > On 06/05/2019 20:32, Vittorio Bertocci wrote: > > To that end, *Karl MCGuinnes

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Resource Owner and the claims are about the Resource Owner. Problem solved? > > Hans. > > On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci > wrote: > >> I am not following. We want this to be adopted, right? :) if we provide >> guidance that is sound but hard to impleme

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

als is disjoint with the space for genuine users or by disallowing > the client_credentials grant altogether. > > This issue already arises in token introspection though, so maybe ought to > be mentioned in the OAuth security topics draft rather than specific to the > JWT AT draft? > > — Nei

Re: [OAUTH-WG] MTLS vs. DPOP

To clarify, I wasn’t suggesting we drop one or the other. Both have their merit and use cases, and both should be developed all the way to standard IMO. But from some preliminary exploration, it seems unlikely that services will adopt both at the same time. From the “pr” perspective, having a

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

-- Mike >> >> >> >> *From:* Hans Zandbelt >> *Sent:* Thursday, April 4, 2019 12:59 PM >> *To:* Mike Jones >> *Cc:* George Fletcher > <40aol@dmarc..ietf.org>>; Vittorio B

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

2019, at 17:13, Vittorio Bertocci < > vittorio.berto...@auth0.com> wrote: > > > > Thank you Torsten for the prompt review and insightful comments! > > > > 2.2.1 - excellent point. I added the suggested language. > > > > 2.2.2 - interesting. I did t

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

rom the on-line Internet-Drafts > directories. > This draft is a 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

[OAUTH-WG] Language in the security BCP for cases where raw U/P is unavoidable

During Daniel's security BCP presentation yesterday, I commented that although I support deprecating ROPG, I also believe we should acknowledge scenarios where U/P use is unavoidable and give clear actionable guidance to developers. Daniel observed that not every scenario is prone to be addressed

Re: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

Thank you Brian for the thorough and insightful review! Comments: > On authenticated encryption. I did chat with Neil about his draft, but as you mention I didn't reference it given that it hasn't bee picked up (yet?). On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My rationale

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

rds, > Torsten. > > > On 21. Jul 2019, at 14:55, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the > IE

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

eb 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-03.txt > Pages : 16 >

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

to aliases from there as well. Thanks! On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci wrote: > Thanks Annabelle. > > Does a mobile app that uses Dynamic Client Registration to establish a >> client secret count as an “authenticated client”? > > I think it should count, t

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

t the very least. > > > > But as I said, I’m reading between the lines here. If this is the > intention, it should be clearly stated. Alternatively, remove (or change to > a SHOULD) the requirement that multi-value `aud` claims must only contain > aliases for the same resource indicator. &g

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

owing for this. Let me stress that I consider this area a nice to have and I am happy to drop it if it's too problematic (in fact it's not in the current spec language). On Mon, Dec 16, 2019 at 11:28 PM Torsten Lodderstedt wrote: > Hi Vittorio, > > > On 17. Dec 2019, at

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

’s > probably not appropriate for this draft, and recommend dropping these > claims. They can always be defined in a separate draft, along with the > other elements necessary to communicate step-up requirements. > > > > – > > Annabelle Richard Backman > > AWS Identity > &

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

; SaaS product that gets tokens from a hosted IDaaS product) I ask because > OIDC clients can specifiy max_age and acr_values, and if client and RS are > owned by the same entity then they can do whatever proprietary thing they > want to indicate the reason for an authorization failure. &

Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

Sorry for the delay here. >From the formal perspective, Torsten's language works for me as well. Thanks for taking the feedback into account. I still worry that without an explicit reference to OIDC implicit+form_post, I will have the conversation "but can we still do this in OIDC now that

Re: [OAUTH-WG] First Draft of OAuth 2.1

appens. What I can say, I have never seen customer complaining > in several years of operation of ASs with refresh token rotation (including > replay detection) for native apps with millions of users. > > best regards, > Torsten. > > Am 12.03.2020 um 19:24 schrieb Vittori

Re: [OAUTH-WG] First Draft of OAuth 2.1

, but imposing those complexities to everyone in the core is asking too much IMO. Thanks V. On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci wrote: > Hey guys, > thanks for putting this together. > I am concerned with the real world impact of imposing sender constraint | > rotation as a MUS

Re: [OAUTH-WG] First Draft of OAuth 2.1

Hey guys, thanks for putting this together. I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario. Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here.

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

SON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > Author : Vittorio Bertocci > Filename: draft-ietf-oauth-access-token-jwt-04.txt > Pages : 17 > Date: 2020-03-06 > > Abstract: >This specifi

Re: [OAUTH-WG] First Draft of OAuth 2.1

d some controls to deal >> with concurrency and additional complexity + performance penalties. And for >> such clients, I was not sure whether or not rotation makes sense. >> >> >> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote: >>

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

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

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

[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] 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] 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

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] 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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

to sign JWT ATs” work better? From: Brian Campbell Date: Wednesday, March 25, 2020 at 14:26 To: Vittorio Bertocci Cc: George Fletcher , Brian Campbell , oauth Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" It seems to me that leaving that ou

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

, March 25, 2020 11:21 AM To: George Fletcher <mailto:gffle...@aol.com> Cc: Brian Campbell <mailto:bcampb...@pingidentity.com>; Vittorio Bertocci <mailto:vittorio.berto...@auth0.com>; oauth <mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profil

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

regardless of type or any other classification.. WDYT? From: Vittorio Bertocci Date: Wednesday, March 25, 2020 at 16:53 To: "Richard Backman, Annabelle" , "vittorio.bertocci=40auth0@dmarc.ietf.org" , 'George Fletcher' , 'Brian Campbell' Cc: 'oauth' Subject: Re: [OAUTH-W

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

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] [UNVERIFIED SENDER] Re: WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

re likely to be applicable. Added a reference to the JWT claims registry in 2.2.2. It was harder to do for SCIM given that we are explicitly feeding those attributes as JWT claims in this very profile. From: "Richard Backman, Annabelle" Date: Wednesday, March 25, 2020 at 17:25 To: Vittorio Berto

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

Alrighty. I added language to explicitly call out 6570 and invalid_token... and eliminated step 7 in the validation for other reasons, indirectly obviating for the need to clarify the reauthentication signaling mechanism. Updating the draft shortly. On 3/25/20, 12:59,

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

Thank you! I updated the language accordingly, and added a warning in the security section aligned with Annabelle’s concerns. Updating the draft shortly. From: Brian Campbell Date: Thursday, March 26, 2020 at 09:47 To: Vittorio Bertocci Cc: George Fletcher , Brian Campbell , oauth Subject

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

0 at 17:53 To: Vittorio Bertocci , "vittorio.bertocci=40auth0@dmarc.ietf.org" , 'George Fletcher' , 'Brian Campbell' Cc: 'oauth' Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Yes, there isn’t a clear solution to

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

" wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens Author

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

Hi Nikos, thanks for taking the time to review and write down your feedback! Inline - In Section 2.2 why nbf claim ( > https://tools..ietf.org/html/rfc7519#section-4.1.5) > is not considered? I > can imagine some interesting applications of

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

discovery” – Annabelle Backman (she/her) AWS Identity https://aws.amazon.com/identity/ From: OAuth on behalf of George Fletcher Organization: AOL LLC Date: Tuesday, March 24, 2020 at 12:56 PM To: Vittorio Bertocci , Vittorio Bertocci , Takahiko Kawasaki Cc: oauth Subject: RE: [EXTERNAL] [OA

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"

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] 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"

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"

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"

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"

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] 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"

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"

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] 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] 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] Call for Adoption: DPoP

+1 On Tue, Mar 17, 2020 at 8:16 AM Mike Jones wrote: > I am for adoption of DPoP. > > > >-- Mike > > > > *From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef > *Sent:* Tuesday, March 17, 2020 5:21 AM > *To:* oauth > *Subject:* [OAUTH-WG]

  1   2   >