Re: [OAUTH-WG] Query on correct approach of calculating the "x5t#S256" parameter in the JWKS response

I agree and share Neil's position. Furthermore, to answer your question, no you should not use or accept both of the approaches as valid methods. Only Method 1 is valid. S pozdravem, *Filip Skokan* On Tue, 16 Jan 2024 at 20:54, Neil Madden wrote: > JWS refers to FIPS 180-4 as the definit

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

on keeping it around. S pozdravem, *Filip Skokan* On Thu, 11 Jan 2024 at 16:07, Karsten Meyer zu Selhausen | Hackmanit < karsten.meyerzuselhau...@hackmanit.de> wrote: > That's an interesting use-case for relay mode and might be a reason to > cover it. > > However, we believ

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

egardless of the response type, e.g. in cases where the authorization request was triggered from an eTLD+1 top level window but the target was authenticating a service that ran on its subdomain, a landing page with a CTA to login sort of setup. S pozdravem, *Filip Skokan* On Wed, 10 Jan 2024 at 09:

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

y given the message structure is not the same as in draft-sakimura-oauth-wmrm. Is that an omission or intentional? S pozdravem, *Filip Skokan* On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit < karsten.meyerzuselhau...@hackmanit.de> wrote: > Hello Filip, > >

Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback

would recommend not using the same response mode name/identifier in your proposal. What prompted you to start a new draft rather than using draft-sakimura-oauth-wmrm-00? S pozdravem, *Filip Skokan* On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit < karsten.meyerzusel

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

Hello Christopher,The wmrm specification use does not require CORS at the authorization endpoint. - Filip9. 3. 2023 v 10:12, Christopher Burroughs :Greetings,I apologize in advance if this question (my first in this list!) is silly :)Regarding CORS support for the authorization endpoint, what

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

I too believe the Errata should be verified. (Although I think the parameter names request and client_id should be in quotes in the corrected text?). S pozdravem, *Filip Skokan* On Tue, 19 Jul 2022 at 15:44, Torsten Lodderstedt wrote: > I’m not sure this requires an update. It basically s

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

believe that a call for adoption is in order so that this document may get worked on under the working group process. Best, *Filip Skokan* On Wed, 20 Apr 2022 at 18:31, Rifaat Shekh-Yusef wrote: > Gentlemen, > > During the last IETF meeting, you volunteered to review the step-up > au

Re: [OAUTH-WG] Regarding iat and nonce in DPoP Proofs

t time window, they ensure freshness, so may need a bit of language afterall. S pozdravem, *Filip Skokan* On Tue, 29 Mar 2022 at 16:23, Jacob Ideskog wrote: > Hi all, > > We have encountered a situation in the wild which I would like to share > and discuss with you. > > We ha

Re: [OAUTH-WG] draft-bertocci-oauth-step-up-authn-challenge - how can an RS signal re-authenticate user, without concern for ACR?

I believe through the use of max_age. - Filip > 24. 3. 2022 v 15:59, Vladimir Dzhuvinov : > > Given the suggested protocol for step up (I just watched the talk in Vienna, > thanks Vittorio & Brian) - how could an RS signal that it simply wants the > end-user re-authenticated, without being

Re: [OAUTH-WG] DPoP + Token Revocation

Hi Dmitry, Sender-constrained access tokens via Client certificate (MTLS) likewise do not require mtls to be used for revocation or introspection (unless it's for client authentication). - Filip On Thu, 10 Feb 2022 at 09:08, Warren Parad wrote: > I'm a big fan of not arbitrarily adding

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

under a single umbrella. Including these changes in -05 may be premature. Best, *Filip Skokan* On Sat, 16 Oct 2021 at 10:12, Warren Parad wrote: > I also support Annabelle's suggestion of idempotent tokens. That would > prevent the relaxation and focus on solving the problem scenario,

Re: [OAUTH-WG] DPoP 03 - access_token as a POST parameter + Bearer/DPoP multi-scheme protected resources

Hello Dmitry, I believe it is the case that DPoP only defines Authorization Header use. Sending a DPoP type access token in a POST body parameter or query string is, unlike with Bearer, not defined. Best, *Filip* On Fri, 3 Sept 2021 at 01:21, Dmitry Telegin wrote: > Hi, > > The Bearer Token

Re: [OAUTH-WG] RAR WGLC comment

I support such change. Odesláno z iPhonu > 19. 6. 2021 v 15:36, Torsten Lodderstedt > : > >  > Hi Brian, > > the idea was to use resource indicators as convenient short cut to support > audience restricted access tokens. However, I agree this can be achieved by > specifying authorization

[OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

ment) might not always be available for control to the webpage depending on where and how it is hosted, on the other hand the HTML it serves always, I hope, is. Best, *Filip Skokan* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

I would support that too but only if the way it's calculated would get aligned as well. If it remains being a fixed sha256 of the whole token rather than what at_hash does, using a new claim makes sense. Odesláno z iPhonu > 9. 4. 2021 v 5:38, Mike Jones : > >  > I had expected that we would

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

The Node.js open source openid-client project ( https://github.com/panva/node-openid-client) likewise implements PAR. Best, *Filip* On Thu, 25 Mar 2021 at 10:40, Filip Skokan wrote: > Hello Hannes, > > the Node.js open source oidc-provider project ( > https://github.com/pan

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

Hello Hannes, the Node.js open source oidc-provider project ( https://github.com/panva/node-oidc-provider) implements PAR behind a feature flag Best, *Filip Skokan* On Wed, 24 Mar 2021 at 20:54, Hannes Tschofenig wrote: > Hi all, > > > > I am working on the shepherd wri

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

Hello Hannes. I am not aware of any IPR related to this document. Cheers, Filip Odesláno z iPhonu > 24. 3. 2021 v 20:52, Hannes Tschofenig : > >  > Hi Torsten, Brian, Nat, Dave, Filip, > > I am working on the shepherd writeup for the "OAuth 2.0 Pushed Authorization > Requests"

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

I don't share the same sentiment about at_hash being a pain, we already have the tools on the server. And browser side it's a matter of 15loc using webcrypto api since, well, the JWS algorithm support there is limited to the simple ones ending with the bitsize needed anyway. Nevertheless if

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

ss tokens. Short `iat` based windows don't help here. S pozdravem, *Filip Skokan* On Thu, 3 Dec 2020 at 12:59, Torsten Lodderstedt wrote: > Hi, > > I'm failing to understand why binding the proof to the access token > ensures freshness of the proof. I would rather think if the client

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

Lodderstedt wrote: > > > > Am 03.12.2020 um 09:56 schrieb Filip Skokan : > > > > There are several documents already mentioning "invalid_redirect_uri" as > an error code, specifically RFC7519 and OpenID Connect Dynamic Client > Registration 1.0. But these don't

Re: [OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

/post/sso-security-redirect-uri/ Best, *Filip* On Thu, 3 Dec 2020 at 10:59, Filip Skokan wrote: > Hello everyone, > > Both RFC 8252 <https://tools.ietf.org/html/rfc8252#section-7.1> and OAuth > 2.1 draft > <https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

[OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

Hello everyone, Both RFC 8252 and OAuth 2.1 draft state that (paraphrasing) Apps MUST use a URI scheme based on a domain name under their control, > expressed in reverse order,

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

There are several documents already mentioning "invalid_redirect_uri" as an error code, specifically RFC7519 and OpenID Connect Dynamic Client Registration 1.0. But these don't register it in the IANA OAuth Extensions Error Registry, presumably because they're neither for the authorization or

Re: [OAUTH-WG] Shepherd writeup for the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens -- Information about Implementations

Hi Hannes, Node.js project oidc-provider (https://github.com/panva/node-oidc-provider) has an option to issue Access Tokens conform to this profile. Best, Filip Odesláno z iPhonu > 17. 9. 2020 v 14:56, Hannes Tschofenig : > > Hi Vittorio, Hi all, > > I am working on the shepherd writeup

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

+1 for keeping it simple. The design itself promotes unique-per-instance keys, not pre-registration. S pozdravem, *Filip Skokan* On Wed, 9 Sep 2020 at 00:46, Brian Campbell wrote: > Indeed there are cases, as you point out, where the key might be knowable > to the server via some other

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

assertions to be passed as Request Objects. Second rejects all future typed JWT profiles from being used as Request Objects without worrying about the claims they may or may not contain. Or is that breaking? S pozdravem, *Filip Skokan* On Fri, 14 Aug 2020 at 00:59, Mike Jones wrote: > At Na

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

? For the record i'm not arguing OAuth 2.0 should be without privacy considerations, i'm just saying - if it did, or rather, regardless if it does or doesn't - PAR does not expand on those in any way. S pozdravem, *Filip Skokan* On Tue, 11 Aug 2020 at 17:17, Denis wrote: > Hi Filip, > >

Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

I don’t think there’s anything new introduced in PAR that would alter existing status quo of privacy consiserations. As such if privacy consideration was to be added for completeness it should be along the lines of “this document does not expand on or otherwise alter the privacy considerations”

Re: [OAUTH-WG] ECDH-1PU encryption algorithm

, *Filip Skokan* On Mon, 10 Aug 2020 at 10:29, Neil Madden wrote: > Thanks Vladimir, > > Responses below > > > On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov > wrote: > > > > Hi Neil, > > > > I definitely like the elegance of the proposed alg for JOSE, i

Re: [OAUTH-WG] OAuth Request JSON Encoding

> 13. 7. 2020 v 18:09, Justin Richer : > > The intent was to only affect the request, not the response, though I can > see the confusion that would arise in having those be at odds with each > other. > > — Justin > >>> On Jul 13, 2020, at 11:47 AM, Filip Sko

Re: [OAUTH-WG] OAuth Request JSON Encoding

Hello Justin, Your ID changes both how a client sends a request as well as how the, already a json, token response is structured (as far as i can see it changes scope from a space separated value to an array). The response morphing will be confusing to clients. I don’t think there’s much to

Re: [OAUTH-WG] client_id in PAR and JAR

transferred” mechanism out. Odesláno z iPhonu > 30. 6. 2020 v 10:15, Thiloshon Nagarajah : > >  > Hi Filip, > > So I'm assuming client_id will be mandated as a query param in PAR as well? > > Regards > >> On Tue, Jun 30, 2020 at 1:09 PM Filip Skokan wrote:

Re: [OAUTH-WG] client_id in PAR and JAR

Hi Thiloshon, Not quite the way it went down but we have this adressed in a future PAR draft. Thank you ;) Filip Odesláno z iPhonu > 30. 6. 2020 v 9:25, Thiloshon Nagarajah > : > >  > Hi All, > > In OAuth JAR specification, client_id is a required query parameter of > authorisation

Re: [OAUTH-WG] OAuth services/libraries wanted for security evaluation...

Hello Pieter, I’m interested for my open source project. Filip Odesláno z iPhonu > 22. 6. 2020 v 15:51, Pieter Philippaerts : > >  > Hello everyone, > > As part of a research project, I've created a test suite to test OAuth 2.0 > implementations and measure how well they implement the

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

’ and developers can still use the non conform ones by passing the well known location directly. Odesláno z iPhonu > 8. 6. 2020 v 11:47, Filip Skokan : > > That question was not clear from your text, you > > Odesláno z iPhonu > >> 8. 6. 2020 v 11:15, Daniel Fet

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

Some products publish both, but they don’t always return the same content, eventho as far as i can tell they should be aliases. The uri normalization of 8414 is also implemented wrong in some cases, since it differs from OIDC as far as issuer path component is concerned. I find it best for AS

Re: [OAUTH-WG] Downgrade attacks on PKCE

I also have #2 in place since ages like others have, or are about to. It just made sense to me to have it that way based on PKCE Section 4.4. The challenge and method are bound to the code to be verified later. When the server issues the authorization code in the authorization response,

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

F%20immediate%20usability%20concerns%22=1=> thread, in my opinion inconclusive, no consensus S pozdravem, *Filip Skokan* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

Hello Brian, can you share the slide deck from yesterday so that we may continue the discussion on the mentioned open questions here on the list? Thank you, Best, *Filip* On Wed, 13 May 2020 at 20:43, Brian Campbell wrote: > Just wanted to note that there is a newer -01 revision of the

Re: [OAUTH-WG] PAR - Can AS/client require request object?

I think require_request_objects has its place, that place should be JAR, PAR as a backup. I believe doing only the "PAR-specific" name / meaning of it would be a missed opportunity. S pozdravem, *Filip Skokan* On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt wrote: > Hi all, &g

Re: [OAUTH-WG] PAR and client metadata

Alternatively, `require_pushed_authorization_requests`. Since we already have the `*require_*request_uri_registration` server and `*require_* auth_time` client metadata properties. WDYT? S pozdravem, *Filip Skokan* On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt wrote: > Hi all, &g

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

I believe implementers should be free to devise their own URIs and not be locked down to one by the spec, at the same time, and RFC6755 subnamespace would be good for guidance. So, I would suggest it be RECOMMENDED to use e.g. `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also that

Re: [OAUTH-WG] PAR - Can AS/client require request object?

g both channels at the same time? And even if so, the Request Object is the same therefore its applicable to both channels the same. Best, *Filip Skokan* On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt wrote: > Hi all, > > this is one of the topics we quickly flipped through in the vi

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

elieve we’ve made a mistake that > allows things to fall through in an insecure fashion. The same argument > against it — ease of porting existing deployments — was raised there as > well, and it won in the end. I hope we can do better this time. > > — Justin > > On Apr 16,

Re: [OAUTH-WG] PAR and client metadata

I would support defining a client level property. I would also support an AS discovery property for an AS-wide policy that is signalled to all clients (and maybe that one would be enough). FWIW (and this touches my earlier responses about the dpop scheme) defining metadata (both AS and Client) is

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

proof) so I don't see how sending two proofs would really work or help the > situation? :facepalm: indeed, sorry. S pozdravem, *Filip Skokan* On Tue, 14 Apr 2020 at 23:39, Brian Campbell wrote: > Hi Filip, > > My attempts at responses to your questions/comments are inline: >

[OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

ualify such cases or allow for sending two proofs, one for the AS to bind refresh tokens to, one for the RS to bind access tokens to? Best, *Filip Skokan* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

or default to end up with an access token with a single audience. A resulting refresh token contains all granted resource values. I don't see this as a conflict but rather further profiling. Ad 2) I disagree with making `aud` optional. S pozdravem, *Filip Skokan* On Tue, 24 Mar 2020 at 07:48

Re: [OAUTH-WG] Call for Adoption: DPoP

I support the adoption of DPoP. Best, Filip > 17. 3. 2020 v 13:21, Rifaat Shekh-Yusef : > >  > All, > > As per the conclusion of the PoP interim meeting, this is a call for adoption > for the OAuth 2.0 Demonstration of Proof-of-Possession at the Application > Layer (DPoP) document: >

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

Yes, that sounds good to me. Best, Filip On Tue, 25 Feb 2020 at 03:18, Nat Sakimura wrote: > So, where should we take it to? > Just add back client_id as it used to be? > > On Fri, Jan 24, 2020 at 6:55 AM John Bradley wrote: > >> >> -- Forwarded message - >> From: John

Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

Hi Mike, Thank you for the implicit dpop draft, quick questions - what htu and htm should be used when used with PAR? - is it fair to say that authorization request provided dpop parameters only apply to authorization endpoint issued access tokens and in case of hybrid flow - the client sends

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

I guess what i meant to call out is that while you and the spec says how omitted fields should be handled, but in the same section earlier it states that all fields must be included. S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 17:35, Justin Richer wrote: > I’m not sure what you

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Sorry, i meant - is top level jti required as well? S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 19:15, Filip Skokan wrote: > Torsten, let's make sure we call out the required top level JWT claims - > iss, iat, aud, what else? is top level iat required as well? > > S pozdrav

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Torsten, let's make sure we call out the required top level JWT claims - iss, iat, aud, what else? is top level iat required as well? S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt wrote: > Hi all, > > based on the recent feedback, Vladimir and

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

” field. It does not mean that the AS leaves the “tos_uri” > field with the value that it previously was (ie, a PATCH style request). > > The AS can reject the update request if it doesn’t want to allow the > client to blank out that field, for whatever reason. > > — Justin &

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

en? S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 16:37, Justin Richer wrote: > Your interpretation was our intent with that. It’s a full replace of the > object. We had debating having PATCH style semantics, but ultimately > decided that that was too complex for the most common

[OAUTH-WG] RFC 7592 - Client Update Request omitted fields

Hello everyone, Section 2.2 of RFC 7592 (Dynamic Client Registration Management Protocol) has the following two statements that oppose one another. This request MUST include all client metadata fields as returned to the > client from a previous

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

conflicts. Last time i brought it up the authors didn't want to consider it because of existing implementations. S pozdravem, *Filip Skokan* On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki wrote: > Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the > same concerns in t

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

I also agree and support that client_id outside of the request object be usable for the purposes described earlier, given that it is also a MUST it be present in the request object with the same value as outside. Odesláno z iPhonu > 31. 1. 2020 v 15:31, Mike Jones > : > > I also agree that

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

A 30x redirect to what is designed to be an authenticated backend client call? Doesn't seem right to me. S pozdravem, *Filip Skokan* On Thu, 16 Jan 2020 at 17:37, Neil Madden wrote: > Why not have the PAR endpoint return a 30x redirect with the full URL to > the authorization en

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

the request_uri must reference a JWT, i know that requirement is in place for the client<>AS contract. I'm fine with a language lifting that particular requirement being present in PAR but i see that as a nitpick that adds little to no real value to the final specification. S pozdravem, *Filip Skokan*

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

orted. > > I strongly perfer #1 as it has a very minor impact on deployments that > don't care (i.e., they just set par_jwks_uri and jwks_uri to the same > value) and failing to support this trust boundary creates an artificial > limit on implementation architecture and could lead to

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

I support the WG adoption of RAR. Best, *Filip* On Mon, 6 Jan 2020 at 20:38, Rifaat Shekh-Yusef wrote: > All, > > This is a call for adoption for the *OAuth 2.0 Rich Authorization > Requests* document. > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ > > Please, let us know if

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

(merge only whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir is describing. S pozdravem, *Filip Skokan* On Mon, 6 Jan 2020 at 07:05, n-sakimura wrote: > Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if > duplicated. > > As of

Re: [OAUTH-WG] PAR metadata

I don't think we need a *_auth_method_* metadata for every endpoint the client calls directly, none of the new specs defined these (e.g. device authorization endpoint or CIBA), meaning they also didn't follow the scheme from RFC 8414 where introspection and revocation got its own metadata. In most

Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

Encrypted JARM responses are in a very similar position. Access Token value is not part of the URL and the response itself is protected. Such response is usually only consumed by a server side application. Same as any form_post response. We could go into further clarifying the client

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

I support the WG adoption of PAR. Best, Filip On Tue, 17 Dec 2019 at 14:01, Daniel Fett wrote: > I support the adoption of PAR. > > -Daniel > > Am 17.12.19 um 13:59 schrieb Rifaat Shekh-Yusef: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

simple to signal by the AS and simple to detect and use by clients using the mtls_endpoint_aliases discovery metadata. S pozdravem, *Filip Skokan* On Fri, 22 Nov 2019 at 09:10, Rob Otto wrote: > Hi Torsten - thanks for the reply.. > > Responses in line. > > Grüsse > Rob > &g

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

I agree with Torsten, plus we're getting sender-constrained refresh tokens for said public clients and SPAs so that the AS doesn't have to (according to the browser based apps draft) rotate them, we all know the pain SPA developers have with those. S pozdravem, *Filip Skokan* On Fri, 22 Nov

[OAUTH-WG] IETF 106 IETF video stream

Hi, I can hear an audio stream but no video has been started yet? Best, *Filip* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

That’s already kind of dealt with in JWE by having claims required for decryption duplicated in the JWE header. Odesláno z iPhonu > 10. 10. 2019 v 19:01, Justin Richer : > ___ OAuth mailing list OAuth@ietf.org

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

request object - client_id must be present in the request object. I wouldn't mind always requiring client_id, and i'm not worried about it not matching e.g. the authorization header because the client authentication middleware in place already takes care of that. S pozdravem, *Filip Skokan* On Thu, 10

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

I find this to be an implementation detail, an optimization. As a matter of fact depending on the Request Object flavor the AS implements a second round of validation may be required. Odesláno z iPhonu > 23. 9. 2019 v 20:46, Janak Amarasena : > ___

Re: [OAUTH-WG] client authentication

Hello Jaap, There are currently 7 registered client authentication methods that are defined by various RFC's. There are the three from RFC6749 which got their names registered in RFC7591 - none,

Re: [OAUTH-WG] Public client cloning

A claimed HTTPS URI would tho, right? Odesláno z iPhonu 10. 9. 2019 v 19:22, Marius Scurtescu : > If the phone is compromised, original app replaced by malicious app, then > RFC8252 will not help. The assumption is that the phone is not compromised. > >> On Tue, Sep 10, 2019 at 9:58 AM

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

are at the implementer’s discretion’ Odesláno z iPhonu 28. 8. 2019 v 23:23, Filip Skokan : > 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

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

- allow combination of parameters from the request object with ones from regular parameters (if not present in request object). S pozdravem, *Filip Skokan* On Wed, 28 Aug 2019 at 23:02, Brian Campbell wrote: > Filip, for better or worse, I believe your assessment of the situation is &

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

ide of the request object. > > There might potentially be reasons for merging (different) URI request > parameters with parameters passed in the request object in cases where long > living request objects are used. > > kind regards, > Torsten. > >> On 27. Aug 2

[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

Re: [OAUTH-WG] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)

Any use:enc, without “use” or “key_ops” or keyops:encrypt/deriveKey that works with a supported algorithm, or one with the JWA “alg”. Odesláno z iPhonu 26. 7. 2019 v 14:01, Brian Campbell : > I'd say this one->* any "enc" key published by the AS on its jwks_uri? > >> On Thu, Jul 25, 2019 at

Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

o be already in place in OIDC. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 20:48, Танги Ле Пенс wrote: > Filip, thank you for your reply. Additional remarks inline. > > On 25.07.2019 21:14, Filip Skokan wrote: > > See my reply inline. > > > > S pozdravem, >

Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

See my reply inline. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс wrote: > In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it > is stated that an error is to be returned when the object request is > invalid. These errors are "inval

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

uot;static" is far from being enough to make a policy decision. S pozdravem, *Filip Skokan* On Thu, 25 Jul 2019 at 13:45, Justin Richer wrote: > This raises an interesting question that I don’t think we’ve addressed > yet: how to appropriately vary token lifetimes and access for differen

Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

Wouldn’t that contradict the security topics BCP? Odesláno z iPhonu 23. 7. 2019 v 9:44, Neil Madden : > Technically it could be optional, but it means that a CSRF attempt will only > be detected by the AS not by the client. If we consider the possibility of a > malicious AS, then this could

Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts

Hello Daniel, everyone, I don't know if this belongs to the DPoP document itself or each respective BCP (especially Browser-Based Apps), but one of the documents should give recommendation to implementers on how to 1. generate the unique private keys per installation / browser session 2.

Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts

a server discovery medatata will be needed so that the RP can know upfront which DSAs are supported on the OP side to validate DPoP Proof JWTs with Best, *Filip Skokan* On Mon, 8 Jul 2019 at 15:30, Daniel Fett wrote: > All, > > In preparation for the meeting in Montreal, I just uploa

Re: [OAUTH-WG] OAuth 2.0 UI/UX Resources?

Hello Daniel, you may gather inspiration and explore Auth0's flows all-in-one page at https://flows.auth0.com Best, *Filip Skokan* On Wed, 3 Jul 2019 at 16:26, Daniel Roesler wrote: > Howdy all, > > Apologies if this is slightly off topic. > > I'm a part of the Green Button Al

[OAUTH-WG] Client Metadata for Resource Indicators for OAuth 2.0

tself that would promote interoperability and would allow its readers to know what to look for in available client metadata.* The format can either be an array of resource values or just like with scope a space-delimited string of resource values. Bes

[OAUTH-WG] MTLS discovery - mtls_endpoint_aliases and _endpoint_auth_methods_supported

Hello everyone, This is a follow to IETF 104 Thursday, March 28, 2019 OAuth meeting where we discussed the MTLS update. In the meeting we discussed the mtls_endpoint_aliases discovery property that exposes mutual-TLS enabled endpoints in addition to ones that don't have mutual-TLS enabled. We're

Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint

Hello Takahiko, Such language already exists in second to last paragraph of section 3.1. Like with CIBA the client’s regular token endpoint auth method is used at the device authorization endpoint. > The client authentication requirements of Section 3.2.1 of [RFC6749] apply to > requests on

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

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 Odesláno z iPhonu 2. 5. 2019 v 22:46, Rifaat Shekh-Yusef : > All, > > As part

[OAUTH-WG] on PKCE for CSRF prevention instead of state parameter

e in the current form? Some might interpret this as if they don't need state to carry any client transaction data they might as well just use PKCE and omit state altogether altho the server does not support PKCE. S pozdravem, *Filip Skokan* ___ OAuth mailin

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

I support the draft's adoption. Best, *Filip Skokan* On Mon, 8 Apr 2019 at 19:07, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens' > document following the positive feedback at the last IETF meeting in Prag

[OAUTH-WG] CORS and the Device Authorization Grant (device flow)

Hello *, I recall implementing an early draft of this flow few years ago for a client landscape composed primarily of older set-top boxes, old and new TV models of various brands (LG, Samsung, Sony) and also HbbTV standards 1.5 and 2.0. I remember having to set up CORS on both the device

Re: [OAUTH-WG] MTLS and SAN

Yes. S pozdravem, *Filip Skokan* On Thu, 4 Apr 2019 at 22:36, Justin Richer wrote: > Thank you, I did miss that text. This should be called out more explicitly > in §2.1, perhaps by specifying that it is only one field. This still > doesn’t set precedence, but it implies that it’s

Re: [OAUTH-WG] MTLS and SAN

ertificate subject value that the authorization server is to expect when authenticating the respective client. Then it lists the different dn/san properties. S pozdravem, *Filip Skokan* On Thu, 4 Apr 2019 at 22:20, Justin Richer wrote: > We’ve just started implementation of SAN-base

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

And here's a real simple client-side implementation using - Webcrypto API - IndexedDB API - fetch https://boiling-escarpment-16732.herokuapp.com/ It's not really a SPA but uses the same browser APIs and no backend other than a web server hosting the html. Best, *Filip Skokan* On Thu, 28 Mar

  1   2   >