[OAUTH-WG] JWT and CWT Status List

Hi all, Christian, Tobias and I would like to draw attention to a new draft we have submitted titled “JWT and CWT Status List” which will be presented at the up and coming IETF 117 meeting during the Friday meeting slot. This draft is related to the group of drafts on verifiable credentials t

[OAUTH-WG] JWT Embedded Tokens

All, Dick, Giuseppe, and I submitted a new version of JWT Embedded Tokens (previously known as Multi-Subject JWT). https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-06.html We would appreciate any feedback on this document. Regards, Rifaat (as individual)

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

On Thu, Mar 18, 2021 at 8:07 AM Neil Madden wrote: > > > On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef > wrote: > > On Thu, Mar 18, 2021 at 3:45 AM Neil Madden > wrote: > >> >> >> On 18 Mar 2021, at 05:33, Andrii Deinega >> wrote: >> >>  >> The Cache-Control header, even with its strongest dir

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

💯 Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Thu, Mar 18, 2021 at 1:07 PM Neil Madden wrote: > > > On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef > wrote: > > On Thu, Mar 18, 2021 at 3:45 AM Neil Madden >

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef wrote: > > On Thu, Mar 18, 2021 at 3:45 AM Neil Madden > wrote: > > >> On 18 Mar 2021, at 05:33, Andrii Deinega > > wrote: >> >>  >> The Cache-Control header, even with its str

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

On Thu, Mar 18, 2021 at 3:45 AM Neil Madden wrote: > > > On 18 Mar 2021, at 05:33, Andrii Deinega wrote: > >  > The Cache-Control header, even with its strongest directive "no-store", is > pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext > Transfer Protocol: Caching). > >

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 18 Mar 2021, at 05:33, Andrii Deinega wrote: > >  > The Cache-Control header, even with its strongest directive "no-store", is > pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext > Transfer Protocol: Caching). > >> This directive is NOT a reliable or sufficient me

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

The Cache-Control header, even with its strongest directive "no-store", is pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext Transfer Protocol: Caching). This directive is NOT a reliable or sufficient mechanism for ensuring > privacy. In particular, malicious or compromised

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

RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud" value or setting it to the AS, the ultimate consumer, appears valid here. Vladimir On 11/02/2021 23:47, Andrii Deinega wrote: > Hi Vladimir, > > What would be a value in the aud claim for refresh tokens? > > Regards, > Andrii

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 11 Feb 2021, at 21:43, Andrii Deinega wrote: > >  > Thank you for the response! Unfortunately, I'm still not convinced that there > is no need for nonce. > > Based on the draft, I don't know how it's possible to achieve a “stronger > assurance that the authorizationserver issued the to

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

Hi Vladimir, What would be a value in the aud claim for refresh tokens? Regards, Andrii On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov wrote: > Hi Warren, > On 08/02/2021 17:59, Warren Parad wrote: > > None of that justified explicitly stating that refresh token introspection > shouldn't b

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Thank you for the response! Unfortunately, I'm still not convinced that there is no need for nonce. Based on the draft, I don't know how it's possible to achieve a “stronger assurance that the authorizationserver issued the token introspection response for an access token, includingcases where t

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 9 Feb 2021, at 22:04, Andrii Deinega wrote: > >  > I still don't see how your #1 and #3 points mitigate the replay attack when > an attacker somehow eavesdrops a successful response from an AS (yes, it's > signed by a public key) and then starts to replay it for other requests from > th

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

I still don't see how your #1 and #3 points mitigate the replay attack when an attacker somehow eavesdrops a successful response from an AS (yes, it's signed by a public key) and then starts to replay it for other requests from the same client. The main problem here is that the client doesn't have

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Three points: 1. In many cases the JWT will be verified using a public key fetched over the same TLS channel. 2. Many proxies can now also produce and consume JWTs for downstream services, so end-to-end JWT is no more guaranteed than end-to-end TLS. 3. The JWT response already contains an iat

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

How can you guarantee that there are always direct TLS connections between a client and an AS hosted say some cloud provider where you have a little control on their infrastructure? Even without all those cloud providers, how can you guarantee the same when there are a bunch of different (software

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

Hi Warren, On 08/02/2021 17:59, Warren Parad wrote: > None of that justified explicitly stating that refresh token > introspection shouldn't be done. At best it suggests that we should > explicitly add language in the draft to directly encourage it. Did you mean discourage? > But if an AS wants

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

On 9 Feb 2021, at 06:55, Andrii Deinega wrote: > >  > Hi WG, > > I wonder if there are any particular reasons to not make nonce a mandatory > parameter for the current JWT Response for OAuth Token Introspection draft. > Or, at least, force an AS to include the nonce claim in a JWT response wh

[OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

Hi WG, I wonder if there are any particular reasons to not make nonce a mandatory parameter for the current JWT Response for OAuth Token Introspection draft. Or, at least, force an AS to include the nonce claim in a JWT response when nonce is presented in the introspection request similar to what

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

None of that justified explicitly stating that refresh token introspection shouldn't be done. At best it suggests that we should explicitly add language in the draft to directly encourage it. But if an AS wants to support it, we shouldn't stop them, or suggest that they can't do it. Allowing refre

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

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify. If the point is to let clients check what authorization they have been given OAuth

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

It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it. Otherwise I could just say why not? And I can go stronger, what's the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the A

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

> Am 08.02.2021 um 00:56 schrieb Warren Parad : > >  >> I‘m therefore leaning towards explicitly stating in our draft that it is not >> intended to be used with refresh tokens. > I'm not following, why explicitly state that it isn't intended. If an AS > wants to provide a similar JSON respons

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

> > I‘m therefore leaning towards explicitly stating in our draft that it is > not intended to be used with refresh tokens. I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

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 the introspection response which indicate

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

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 the introspection response which indicates that this access token is active (using RFC7662). An OAuth client queries the AS to

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

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

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

Hi WG, draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is tr

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

I'm not aware of any IPR that pertains to this specification. -- Mike -Original Message- From: Hannes Tschofenig Sent: Monday, September 21, 2020 12:22 PM To: John Bradley ; nat@nat.consulting; Mike Jones Cc: oauth@ietf.org Subject: JWT Secured Authoriz

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

ess token might not roll off the tongue, but at this point ‘JWT’ is > nearly a proprietary eponym and the expression “JWT token” is extraordinarily > common in literature, a quick google query will give you the full measure of > the phenomenon, hence I think we’ll be OK with the current

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

ature, a quick google query will give you > the full measure of the phenomenon, hence I think we’ll be OK with the > current form. > > Cheers, > > V. > > > > *From:* Andrii Deinega > *Sent:* Tuesday, October 6, 2020 2:25 PM > *To:* vittorio.berto...@auth0.co

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

OK with the current form. Cheers, V. From: Andrii Deinega Sent: Tuesday, October 6, 2020 2:25 PM To: vittorio.berto...@auth0.com; oauth@ietf.org Cc: Jim Manico ; Nicolas Mora Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint Vittorio and WG, Would it be possible

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

tho I know a lot of people don’t like it as it perpetrates the offline_access original sin 😊 -Original Message- From: Jim Manico Sent: Tuesday, October 6, 2020 2:31 PM To: vittorio.berto...@auth0.com; 'Nicolas Mora' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT access

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

approaches above? If yes, where would that live? I am not sure the JWT AT profile is the right place, perhaps an addendum to the current revocation specs? From: OAuth On Behalf Of Thomas Broyer Sent: Tuesday, October 6, 2020 5:17 AM To: Nicolas Mora Cc: Subject: Re: [OAUTH-WG] JWT access

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

s scope for influencing RTs and Ats (in particular, in the context of SPAs) but that's additional semantic that isn’t defined today. -Original Message- From: OAuth On Behalf Of Jim Manico Sent: Sunday, October 4, 2020 5:17 PM To: Nicolas Mora Cc: oauth@ietf.org Subject: Re: [OAUTH-W

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

ober 4, 2020 5:17 PM > To: Nicolas Mora > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > In this model, considering that token revocations don't happen a lot... > > Just a brief note, a secure piece of software makes the

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

ing RTs and Ats (in particular, in the context of SPAs) but that's additional semantic that isn’t defined today. -Original Message- From: OAuth On Behalf Of Jim Manico Sent: Sunday, October 4, 2020 5:17 PM To: Nicolas Mora Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT access tokens

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

On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora wrote: > Hello, > > Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > > > There might be some kind of pushed events between the AS and the RS > when > > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at > all. > > Like this,

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

> In this model, considering that token revocations don't happen a lot... Just a brief note, a secure piece of software makes the logout feature prominent. Every logout event should trigger token revocation. I’m mentioning this because a lot of OAuth solutions in the mobile space literally igno

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

Hello, Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > There might be some kind of pushed events between the AS and the RS when > a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all. > Like this, the RS knows if a JWT AT has been revoked or not. > > > If there ar

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

Disclosure: I have not read the draft on JWT AT, those comments are based only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT. Le sam. 3 oct. 2020 à 19:18, Nicolas Mora a écrit : > My 2 cents, > > Le 20-10-02 à 18 h 19, Andrii Deinega a écrit : > > > > Here is what I would like t

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

My 2 cents, Le 20-10-02 à 18 h 19, Andrii Deinega a écrit : > > Here is what I would like to get a better understanding of: > 1. How should a response of the introspection endpoint look like if the > RS makes an attempt to introspect a JWT access token? AFAIK, the RFC doesn't specify if the intr

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

Hi WG, https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 provides the flowing about JWT access tokens “resource servers can consume them directly for authorization or other purposes without any further round trips to introspection ( [RFC7662]) or userinfo [OpenID.Core]) endpoints.”

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

I know of no IPR, and make the required contributions again. On Mon, Sep 21, 2020, 4:22 PM Hannes Tschofenig wrote: > Hi Mike, Nat, John, > > I am updating the shepherd writeup for the "The OAuth 2.0 Authorization > Framework: JWT Secured Authorization Request (JAR)" specification, see > https:/

[OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

Hi Mike, Nat, John, I am updating the shepherd writeup for the "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" specification, see https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt, and given the changes I need your IPR confirmation again. (Mike joined as

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

; > Thanks! > > V. > > > > *From: *OAuth on behalf of Prabath Siriwardena > > *Date: *Thursday, May 7, 2020 at 11:56 > *To: *Rifaat Shekh-Yusef , oauth > *Subject: *[OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding > state into the JWT > > >

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

is on its way out of the grants stage, hence doing major changes to accommodate its quirks wouldn’t give a lot of ROI. HTH Thanks! V. From: OAuth on behalf of Prabath Siriwardena Date: Thursday, May 7, 2020 at 11:56 To: Rifaat Shekh-Yusef , oauth Subject: [OAUTH-WG] [JWT Profile for OAuth 2.0

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

Hi all, Can we say in [1], that the AS should add the value of *state* parameter from the authorization request (if present), to the JWT access token it generates? This will help to address token injection issue [2], with respect to the implicit grant type. Appreciate your thoughts on this. [1]

Re: [OAUTH-WG] JWT profile and IdentityServer

Oh - and last thing I forgot to mention. We had the luxury of designing IdentityServer from the ground up after OIDC has been released. So it really was fine tuned to be a OIDC + OAuth implementation. Hence the strong semantics of the sub claim for both the OIDC and OAuth parts. We think this is r

Re: [OAUTH-WG] JWT profile and IdentityServer

Hey, No problem - this email was not intended to make you change the document. Just my conclusions. OK - let me just set the scene first * IdentityServer is not a “off the shelf” product or SaaS - it is a framework. IOW - developers have much greater flexibility and less constraints to implement

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 us

[OAUTH-WG] JWT profile and IdentityServer

Hey, Just some notes on applying the JWT profile to IdentityServer * we emit the at+jwt typ - that’s very useful * we emit iat in addition to nbf (if we would remove nbf, we would break the .NET JWT library from Microsoft - I guess that’s the reason AAD emits it as well) * we have an option to em

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I agree with this as well. Rob On Tue, 17 Mar 2020 at 12:40, Vladimir Dzhuvinov wrote: > +1 > > Thanks! > > Vladimir > On 12/03/2020 17:31, Brian Campbell wrote: > > +1 (again) that `client_id` should be allowed/required as a query > parameter outside the request object JWT or URI and that its

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

+1 Thanks! Vladimir On 12/03/2020 17:31, Brian Campbell wrote: > +1 (again) that `client_id` should be allowed/required as a query > parameter outside the request object JWT or URI and that its value has > to be the same as within the request object. > > On Thu, Mar 12, 2020 at 8:20 AM Joseph He

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

So, I am getting overwhelming approval on getting client_id back. In the next few days, I will create another draft that has it back. Best, Nat Sakimura On Fri, Mar 13, 2020 at 1:25 AM George Fletcher wrote: > I'm a +1 for adding client_id back as well > > On 3/12/20 11:31 AM, Brian Campbell w

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I'm a +1 for adding client_id back as well On 3/12/20 11:31 AM, Brian Campbell wrote: +1 (again) that `client_id` should be allowed/required as a query parameter outside the request object JWT or URI and that its value has to be the same as within the request object. On Thu, Mar 12, 2020 at 8:2

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

+1 (again) that `client_id` should be allowed/required as a query parameter outside the request object JWT or URI and that its value has to be the same as within the request object. On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan wrote: > I agree with that too. > > Joseph > > On 12 Mar 2020, at 14

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I agree with that too. Joseph > On 12 Mar 2020, at 14:18, Mike Jones > wrote: > > I agree that we should restore the client_id functionality. Thanks for > moving this forward! > >-- Mike > > From: OAuth mailto:oauth-boun...@ietf.org

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I agree that we should restore the client_id functionality. Thanks for moving this forward! -- Mike From: OAuth On Behalf Of Nat Sakimura Sent: Monday, February 24, 2020 6:18 PM To: John Bradley Cc: oauth Subject: Re: [OAUTH-WG] Fwd: [EX

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): signing

On Tue, Jan 14, 2020 at 04:29:39PM -0500, George Aristy wrote: > Hello everyone. > > Is it possible to relax the requirement to sign the claims set if an > authenticated encryption mode with prior shared secrets is used? Eg. > https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02. This would >

[OAUTH-WG] JWT Secured Authorization Request (JAR): signing

Hello everyone. Is it possible to relax the requirement to sign the claims set if an authenticated encryption mode with prior shared secrets is used? Eg. https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02. This would reduce the size of the request object substantially. Regards, George Aris

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

The intent was to do that, but specs change once the OAuth WG and IESG get there hands on them. Being backwards compatible with OIDC is not a compelling argument to the IESG. We were mostly thinking of asymmetric encryption. Specifying puting the issuer and or the audience in the headder has com

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Yes, putting the client_id into the JWE header is a way around the need to have the client_id outside the JWE as top-level authZ request parameter. Unfortunately this work around isn't mentioned anywhere, I just checked the most recent draft-ietf-oauth-jwsreq-20. Our DDoS attack mitigation (for O

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Vladimir, For that very case the payload claims may be repeated in the JWE protected header. An implementation wanting to handle this may look for iss/client_id there. Odesláno z iPhonu > 10. 1. 2020 v 21:19, Vladimir Dzhuvinov : > > I just realised there is one class of JARs where it's pr

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I just realised there is one class of JARs where it's practially impossible to process the request if merge isn't supported: The client submits a JAR encrypted (JWT) with a shared key. OIDC allows for that and specs a method for deriving the shared key from the client_secret: https://openid.net/s

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

> Am 10.01.2020 um 16:53 schrieb John Bradley : > > I think Torsten is speculating that is not a feature people use. I’m still trying to understand the use case for merging signed and unsigned parameters. Nat once explained a use case, where a client uses parameters signed by a 3rd party (

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Yes that is what it comes down to. Is that a feature having a fixed set of parameters in the signed JAR and some number of OAuth parameters unsigned outside the JAR, that people want badly enough for us to pull the spec back and restart IESG review. I think Torsten is speculating that is not a fe

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

But merge gives us the ability, which has been stated here before, to have a fixed core set of parameters inside the JAR and a mixed set of variable parameters outside the JAR. What if by “merge” we really mean “you can’t repeat things in both places but you can have fields in either”. — Just

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I haven't seen any real use of merge. It happens with Connect as a side effect of OAuths current requirement to have some of the parameters outside the JAR. Nothing stops servers from ignoring parameters outside JAR or acting on query parameters outside the JAR if they are not in the OAuth regis

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

s e-mail is confidential and intended for the >> named recipient only. >> If you are not an intended recipient, please notify the sender and delete >> this e-mail. >> >> From: OAuth <mailto:oauth-boun...@ietf.org> On >> Behalf Of Justin Richer >>

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

> Am 06.01.2020 um 23:50 schrieb John Bradley : > > A client could duplicate those outside the request object for some sort of > backwards compatability but they will be ignored. > Is this used for backward compatibility with the OIDC servers? > What we have lost is the merge capability. Ther

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

If you are not an intended recipient, please notify the sender and > delete this e-mail. > >   > > *From:*OAuth *On Behalf Of *Justin Richer > *Sent:* Friday, January 3, 2020 2:35 AM > *To:* Takahiko Kawasaki > *Cc:* Brian Campbell ; > oauth ; Nat Sakimura > *Subject

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

> >> Nat Sakimura >> >> Research Fellow, Nomura Research Institute >> >> E: n-sakim...@nri.co.jp >> >> T: +81(90)60136276 >> >> ------------- >> >> PLEASE READ:This e-mail is confidential a

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

ent only. > > If you are not an intended recipient, please notify the sender and delete > this e-mail. > > > > *From:* OAuth *On Behalf Of *Justin Richer > *Sent:* Friday, January 3, 2020 2:35 AM > *To:* Takahiko Kawasaki > *Cc:* Brian Campbell ; oauth > ; Nat Sakimu

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

2020 2:35 AM To: Takahiko Kawasaki Cc: Brian Campbell ; oauth ; Nat Sakimura Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object For solution [2], this is the behavior that’s required for OIDC today, so I would say that’s the New Client behaving like an O

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Why not leave this to be an AS policy, or to be defined by specific profiles? We have had a simple AS setting which allows or prohibits parameters outside the JWT: * If parameters outside the JWT are allowed, they are merged, with the JWT-secured ones having precedence. * If parameters o

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

For solution [2], this is the behavior that’s required for OIDC today, so I would say that’s the New Client behaving like an Old Client in order to talk to an Old Server. So in reality, (2) causes the request to be rejected, and that’s OK. I don’t think it’s viable to require parameters to exis

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Thank you, Justin. Actually, I wanted to see someone write a summary about what happens in each combination from a viewpoint of both RP and AS with regard to backward compatibility (as I told you in other channel just before you posted your email ^_^). So, *(1) New Client + New Server* No problem

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I think the nature of the backwards incompatibility is important here. The way that things are now, using merge-with-precedence, you have the following matrix of compatibility: New Server | Old Server | ---+-+--+ New Client | YES| NO

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Breaking backward compatibility in this part would mean that OpenID Certification given to AS implementations with request_uri support will be invalidated once they support JAR. It also would mean that test cases in the official conformance suite need to be changed in a backward-incompatible manner

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

So, no change is OK? On Wed, Dec 11, 2019 at 10:01 PM John Bradley wrote: > I also slightly prefer the merge approach. > > There are plusses and minuses to both. > > Changing again now that it is past ISEG review and backing out a Discuss > will add another three to six months at this point, if

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I also slightly prefer the merge approach. There are plusses and minuses to both. Changing again now that it is past ISEG review and backing out a Discuss will add another three to six months at this point, if we can get them to agree to the change. John B. On Tue, Dec 10, 2019, 11:29 PM Nat Sa

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

My preference would be that if a request object is used, all parameters must go in there a) makes the AS implementation easier b) there is really no point (IMO) to have a mixture of signed and unsigned parameters c) certain parameters should go into the RO - e.g. the code_challenge to prevent the

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Correct. The WG supported the precedence approach and even merge just like OIDC as it is very useful from the implementation point of view and helps with a bunch of deployment patter. The push back came in from the Ben Campbell’s DISCUSS. See https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I'm sorry for this late response, but I'm also afraid that the requirement "the authorization server supporting this specification MUST only use the parameters included in the request object." in Section 6 of the draft 20 is problematic. Wha

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

> Am 28.08.2019 um 23:23 schrieb Filip Skokan : > > - allows merging request object and regular parameters with request object > taking precedence since it is a very useful feature when having pre-signed > request object that's not one time use and clients using it wish to vary > state/nonce

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

FWIW, as best I can remember the change in question came as I result of directorate/IESG review rather than a WG decision/discussion. Which is likely why you can't find the "why" anywhere in the mailing list archive. On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote: > Well it kind of blows, do

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

It would be fine not allowing that across the board but rather through a language like so ‘Authorization Servers MAY allow per-transaction parameters such as “state” and “nonce” to be sent outside of the Request Object using regular OAuth 2.0 parameter syntax, the specific parameters are at the

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere in the mailing list archive around the time this was changed. My take on satisfying both worlds looks like this - allow just JAR - no other params when possible. (which btw isn't possible to do with request_uri when e

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Filip, for better or worse, I believe your assessment of the situation is correct. I know of one AS that didn't choose which of the two to follow but rather implemented a bit of a hybrid where it basically ignores everything outside of the request object per JAR but also checks for and enforces the

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I can get by not having to have the minimum oauth request parameters, but the current language does not imply that one can use the parameters if they’re not present in the Request Object. That derails JAR from its OIDC variant. Odesláno z iPhonu 28. 8. 2019 v 10:48, Torsten Lodderstedt : >

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Hi Filip, In my understanding, duplication of request parameters outside of the request object was necessary in the OIDC variant in order to retain OAuth compliance. JAR as an OAuth extension will not require the client to duplicate OAuth request parameters outside of the request object. The

[OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Hello everyone, in an earlier thread I've posed the following question that might have gotten missed, this might have consequences for the existing implementations of Request Objects in OIDC implementations - its making pure JAR requests incompatible with OIDC Core implementations. draft 14 of jw

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure

Rifaat, I’m not aware of any IPR regarding https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/. kind regards, Torsten. > Am 31.05.2019 um 14:25 schrieb Rifaat Shekh-Yusef : > > Torsten and Vladimir, > > As part of the shepherd write-up for the JWT Response for OAuth

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure

Hello Rifaat, On 31/05/2019 15:25, Rifaat Shekh-Yusef wrote: > Torsten and Vladimir, > > As part of the shepherd write-up for the *JWT Response for OAuth Token > Introspection* document, we need an IPR disclosure from you. > > Are you aware of any IPRs related to this document? > https://datatrack

[OAUTH-WG] JWT Response for OAuth Token Introspection - IPR Disclosure

Torsten and Vladimir, As part of the shepherd write-up for the *JWT Response for OAuth Token Introspection* document, we need an IPR disclosure from you. Are you aware of any IPRs related to this document? https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ Regards, Ri

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations

Thanks Steffo! On Friday, May 17, 2019, Steffo Weber wrote: > Hi Rifaat > > We did one as part of the ForgeRock platform (on a per project basis). > Artefact can be found at: https://github.com/ForgeRock/ > PSD2-Accelerators/tree/yes.com/openig/yes-openig-signed-introspect-filter > We might move

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations

Hi Rifaat We did one as part of the ForgeRock platform (on a per project basis). Artefact can be found at: https://github.com/ForgeRock/PSD2-Accelerators/tree/yes.com/openig/yes-openig-signed-introspect-filter We might move that to a different service within the platform at a later stage. HTH

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations

Thanks Vladimir! On Mon, May 6, 2019 at 2:40 PM Vladimir Dzhuvinov wrote: > Hi Rifaat, > > On 02/05/2019 23:46, Rifaat Shekh-Yusef wrote: > > All, > > > > As part of the shepherd write-up for the *JWT Response for OAuth Token > > Introspection* draft, we are looking for information about > imple

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection implementations

Thanks Filip! On Fri, May 3, 2019 at 3:32 AM Filip Skokan wrote: > Hi Rifaat, > > node.js OSS oidc-provider implements the document in full behind an > optional feature toggle - > https://github.com/panva/node-oidc-provider/blob/master/docs/README.md#featuresjwtintrospection > > Best, > Filip >

  1   2   3   >