[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-attestation-based-client-auth-03.txt

On Fri, May 31, 2024 at 02:38:29AM -0700, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-oauth-attestation-based-client-auth-03.txt is now > available. It is a work item of the Web Authorization Protocol (OAUTH) WG of > the IETF. > >Title: OAuth 2.0 Attestation-Based Client Auth

Re: [OAUTH-WG] client_id in CWT Claims

I did not do a full in-depth research on this topic, but it looks like my AD review of what became RFC 9200 (https://mailarchive.ietf.org/arch/msg/ace/k5RzWwmuawvczrHN88JoE3vbH78/) noted that what-became-RFC8693 had already gotten "scope" registered in the JWT claims registry, so that RFC 9200 coul

Re: [OAUTH-WG] [COSE] .well-known/jwks.json and constrained-voucher and RFC7517

On Tue, Jul 12, 2022 at 09:46:01PM +0200, Warren Parad wrote: > I don't know if this is relevant, but jwks.json isn't registered, because > it doesn't have to be at that location. The > /.well-known/openid-configuration discovery document, which is registered, > uses the jwks_uri property to specif

Re: [OAUTH-WG] DPoP JWT claims

On Thu, Jun 16, 2022 at 04:18:49PM -0600, Brian Campbell wrote: > I'm not sure the JWT claims registry has turned out to be exactly what was > envisioned. And, to your point, the utility of some of the registrations is > questionable. The issue of name conflicts vs reuse is more subtle than it > s

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

On Thu, Dec 09, 2021 at 09:59:58PM +0100, Warren Parad wrote: > > If we want to signal that the token should be used with mTLS and not > without, that to me says "claim" as "*mtls: true"*. Further, Bearer says > "use this as is, it doesn't need to be modified", the token doesn't need to > be mod

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-iss-auth-resp-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OAUTH-WG] How to report a possible security threat

On Sat, Aug 28, 2021 at 03:56:51PM +0200, Rutger Hertogh wrote: > Hi all, > > How can I report a possible security threat? The answer depends on whether it's believed to be an issue with the protocol itself vs a specific implementation or implementations of it. The IETF guidance on reporting pro

[OAUTH-WG] [mglt.i...@gmail.com: Re: [Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz]

Hi OAuth-ers, Just a heads-up that ACE is doing a quick WGLC to confirm that we should register a new "cti" introspection parameter in our core spec, to match up with the CWT token identifier claim of that name. The document is already in the RFC Editor's queue, so I wanted to raise visibility of

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

On Thu, Aug 12, 2021 at 05:05:03PM -0600, Brian Campbell wrote: > Indeed but this case would be only distinguishing between which of the two > things (token & proof) the client sent was invalid. It seems like a > reasonable amount of information to disclose that might be helpful in > troubleshootin

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

It's not immediately obvious to me that making the distinction is good (but I'm also basically devoid of the context in which this exchange will occur). With security protocols there can be risks from overly descriptive errors, which might (e.g.) leak information that "this is a valid token" vs "t

Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

On Thu, Aug 12, 2021 at 02:17:24PM -0600, Brian Campbell wrote: > It might be worth a mention but I'm always a little hesitant about > potentially repeating content from other specs (and maybe even getting it > wrong!). Maybe a very brief mention along with a pointer to that section in > RFC 7235 w

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT)

a new revision out until next > week sometime. Understandable! > On Mon, Jun 28, 2021 at 1:45 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-par-08: Yes > > &

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-par-08: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-par-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619)

On Wed, Jun 23, 2021 at 12:04:47AM +, Dave Isaacs wrote: > Fair enough, I guess. The HTML versions of the older RFCs must be peppered > with bad links if this is the case. Yes, that is true, and we get some periodic errata reports of this nature as well. I marked this report as rejected per

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613)

This looks correct to me; could the authors/WG please confirm? Thanks, Ben On Thu, Jun 17, 2021 at 12:04:37PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -- > You

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

w, prefixed by "Mike>". > > -Original Message----- > From: OAuth On Behalf Of Benjamin Kaduk via > Datatracker > Sent: Tuesday, April 6, 2021 11:39 AM > To: The IESG > Cc: oauth@ietf.org; oauth-cha...@ietf.org; draft-ietf-oauth-jws...@ietf.org > Subject: Benjamin

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

Hi Roberto, On Fri, Apr 02, 2021 at 11:55:27AM +0200, Roberto Polli wrote: > Hi Vittorio et al, > > some considerations on oauth access token jwt follows. > You can see them here too > https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit > > An example with client

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

On Thu, Apr 01, 2021 at 01:32:08PM -0700, Martin Duke via Datatracker wrote: > Martin Duke has entered the following ballot position for > draft-ietf-oauth-access-token-jwt-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-access-token-jwt-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-32: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OAUTH-WG] Nonce-based Replay Protection for DPoP

On Tue, Mar 16, 2021 at 05:45:46PM -0400, Rifaat Shekh-Yusef wrote: > Brian, > > For a nonce-based replay protection you. might want to look at the ACME > protocol here: > https://tools.ietf.org/html/rfc8555#section-6.5 Yes, that one is really solid for the sort of thing it does, and I find mysel

Re: [OAUTH-WG] OAuth mTLS and JWK use/key_ops

On Mon, Mar 08, 2021 at 01:19:46PM +, Neil Madden wrote: > > > > On 8 Mar 2021, at 12:50, Neil Madden wrote: > > > > An interesting question was raised by our developers around the > > interpretation of JWK “use” and “key_ops” constraints when publishing a > > self-signed certificate for

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)

s a lot for your comments. > > We discussed them and applied several changes to the draft to address them. > > Those changes can be previewed here: > > https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response/compare/address-comments-benjamin-kaduk-2021-01-26 >

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314)

an RFC, that would explain why the > script failed. Can we do a manual fix after the script has run to update > the RFC? > > On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk wrote: > > > On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: > > > --VERIFI

Re: [OAUTH-WG] [Errata Rejected] RFC8176 (6314)

On Tue, Oct 20, 2020 at 09:21:45AM -0700, RFC Errata System wrote: > --VERIFIER NOTES-- > Errata reports are for reporting issues with the authoritative RFC version(s) > as published by the RFC Editor. RFC 8176 predates the usage of the "v3 XML" > format, so the plain text version is the autho

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

Hi Denis, On Wed, Sep 02, 2020 at 10:39:07AM +0200, Denis wrote: > Hi Ben, > > This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to > discuss one of the topics raised in: > Last Call: (JWT > Response for OAuth Token Introspection) to Proposed Standard > > Only the text releva

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

Hi all, On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote: > The last text that has been proposed on the list about this thread is > the following: > > Implementers should be aware that a token introspection request lets the > AS know when the client is accessing the RS, >   which can

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

plicit typing > wouldn't help in that situation. > > On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > > > -- > > COMMENT: > > ---

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

Hi Nat, Also inline. On Thu, Aug 13, 2020 at 11:25:27PM +0900, Nat Sakimura wrote: >Thanks Benjamin. >My replies inline below: >On Wed, Aug 12, 2020 at 12:53 AM Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following b

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

On Tue, Aug 11, 2020 at 02:35:20PM -0600, Brian Campbell wrote: > I also suspect the Jwsreq authors won't respond to this and the > request/suggestion will be ignored. Which is discouraging. I realize it's > late in the process for this document but it's been in IESG Evaluation > since early 2017.

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

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

On Tue, Jun 09, 2020 at 09:42:27AM +0200, Daniel Fett wrote: > Am 09.06.20 um 00:50 schrieb Benjamin Kaduk: > > On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: > >> Hi Filip, > >> > >> Thanks for your answers! > >> > >> I'm

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

On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: > Hi Filip, > > Thanks for your answers! > > I'm not quite sure if the wording in my question was clear: My main > concern is the difference between > https://example.com/some/path*/.well-known/oauth-authorization-server* > and > https:

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

Hi Denis, On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: > Hi Benjamin, > > Responses are between the lines. > > > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > >> Hi Benjamin, > >>> On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > Since then, I questioned myself

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

ntioning it! -Ben > > If that is not the case, which kind of scenarios would occur for an AS to > respond with the error code "invalid_token"? > > Best Regards, > Janak Amarasena > > On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk wrote: > >

Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

hashes from bruteforcing once the dataset is exfiltrated) of hashes > pushed me to reach out. > > -- > Dmitry Khlebnikov > Senioe Security Adviser // REA Group > +61 428 425291 > > ________ > From: Naveen Agarwal > Sent: Tuesday, 2

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

On Sun, May 31, 2020 at 12:58:54PM -0500, Pete Resnick wrote: > On 31 May 2020, at 12:47, Barry Leiba wrote: > > >> But > >> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, > >> in particular: > >> > >> Only errors that could cause implementation or deployment problems

Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote: > As indicated in the abstract: > > "This document introduces the ability to send request parameters in > a JSON Web Token (JWT) instead, >   which allows the request to be signed with JSON Web Signature (JWS)". > > This approach

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

t; > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6187 > > > > -- > > Status: Verified > > Type: Editorial > > > > Reported by: Pete Resnick > > Date Reported: 2020-05-26 > > Verified

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

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > Hi Benjamin, > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > >> Since then, I questioned myself how a client would be able to request an > >> access token that would be > >> *strictly compliant with this Profile*. > > I don't und

Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

Authors, WG, any comments? Right now the likely dispositions seem to me to be Editorial/HFDU or Rejected; the text is noting that salting is not used and attempting to give an explanation of why that's the right choice. It's not clear that the WG was in error to include some such discussion at th

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

On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > > Since then, I questioned myself how a client would be able to request an > access token that would be > *strictly compliant with this Profile*. I don't understand why this is an interesting question to ask. The access token and interpre

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

My apologies for a tangent on an already-long thread... On Fri, May 08, 2020 at 08:50:16AM +0200, Daniel Fett wrote: > > Yes, this will make a number of implementations non-spec-compliant, but > I do not think that this is a huge problem. Software needs to adapt all > the time and a software that

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

Hi Denis, Sorry for the slow response. I had several deadlines this week and couldn't think much farther ahead than the next one, so my INBOX fell behind. On Mon, May 04, 2020 at 12:36:05PM +0200, Denis wrote: > Hello Benjamin, > > First of all, you don't need to use an aggressive language to s

Re: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks

Hi Denis, On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote: >Comments on draft-ietf-oauth-dpop-00. > >1) In section 9 (Security considerations), the text states: > >DPoP does not, however, achieve the > same level of protection as TLS-based methods such as OAuth Mu

Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

On Fri, May 01, 2020 at 02:29:02AM +, Mike Jones wrote: > * Is the DPoP signature really needed when requesting a bound token? It > seems like the worst that could happen would be to create a token bound to a > key you don't control, which you couldn't use. Daniel expressed concern > a

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

Hi Denis, You seem to be continuing to be operating under incorrect assuptions about how OAuth 2.0 works, and have proceeded to make long chains of reasoning that, unfortunately, are not based on a solid foundation. In order to reduce the amount of frustration amongst all participants, in the fut

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

On Mon, Apr 27, 2020 at 12:58:09PM -0400, Justin Richer wrote: > I agree that any URI could be used but that it MUST be understood by the AS > to be local to the AS (and not something that can be impersonated by an > attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an > op

Re: [OAUTH-WG] Structured management of working documents

Hi Jared, On Thu, Apr 23, 2020 at 09:55:21PM -0500, Jared Jennings wrote: > Hi all, > > I know I am super new to the list, so bare with me with my > observations that I would like share with the group. Probably no one in the > list knows me, but I am used to online forms, mailing lists and I been

Re: [OAUTH-WG] OAuth GREASE

On Thu, Apr 23, 2020 at 04:52:49PM +, Mike Jones wrote: > > I’d personally point out these non-compliant behaviors to the vendors and ask > them to fix them. Their non-compliance makes it harder for clients to > interoperate with them, hurting both. Name names, if that’s what it takes. My

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

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 simply says by section 4.1.2 > of SCIM Core in a bloc

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

Hi Denis, I am going to top-post because the quoting in this thread has become pretty mangled. First off, thank you for calling out the text in the document about scenarios where "the authorization server and resource server are not co-located, are not run by the same entity, or are otherwise sep

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

On Tue, Apr 07, 2020 at 03:31:09PM -0600, Brian Campbell wrote: > One of the primary motivations for the proof-of-possession mechanism of > DPoP being at the application layer was to hopefully enable implementation > and deployment by regular application developers. A lesson learned from the > diff

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

On Mon, Apr 06, 2020 at 12:05:28PM -0600, Brian Campbell wrote: > Hi Mike, > > Thanks for your interest in the work and review of the draft. As one of the > too-many authors on the document, I attempt to answer questions and respond > to comments inline below. Though I admit to not having necessar

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

On Tue, Mar 31, 2020 at 09:33:35PM +, Vittorio Bertocci wrote: > > > I’ve already replied to the other thread, but I’ll note that “different > > strengths, different lifecycles” don’t matter much if the RS will accept > > both types of tokens, signed with either key. > point taken. I applied

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

Hi Torsten, Sorry for the delayed response; it seems this got buried beneath some other things. Thanks to everyone else for contributing, and I think there's just one point left that needs a response (inline)... On Mon, Mar 02, 2020 at 03:19:11PM +0100, Torsten Lodderstedt wrote: > Hi Ben, > >

Re: [OAUTH-WG] OAuth WG Virtual Meeting During IETF 107?

On Fri, Mar 13, 2020 at 10:37:50AM -0700, William Denniss wrote: > Now that the IETF 107 virtual meeting agenda was posted > , > and only includes BOFs and new WGs, should we schedule our own virtual > meeting for the

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

Hi Torsten, Sorry for the delayed response, but since I was explicitly listed in the "To:" field I expect the response is still of interest. On Wed, Mar 04, 2020 at 05:19:13PM +0100, Torsten Lodderstedt wrote: > Hi all, > > based on the recent feedback, Vladimir and I propose the following chang

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

On Fri, Feb 28, 2020 at 03:44:05PM +0100, Torsten Lodderstedt wrote: > Hi Ben, > > > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker > > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-jw

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

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

has IANA > request so it needs to be referred back to IANA. > > The IETF datatracker status page for this draft is: > datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > Best, > > Nat Sakimura > > 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker : > >

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

r addresses the encryption issue without > >> merging. > >> > >> I understand that some existing servers have dependencys on getting the > >> clientID as a query paramater. > >> > >> Is that the only paramater that people have a issue with as opos

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

ltimately this is an internal implementation of the AS. It could just as > easily be using data URIs containing a symmetrically encrypted database > record ID. > > > On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk wrote: > > > > On Thu, Jan 16, 2020 at 04:31:30P

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

On Thu, Jan 16, 2020 at 04:31:30PM +, Neil Madden wrote: > The mitigations of 10.4.1 are related, but the section heading is about > (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF > attacks too or else add another section with similar mitigations. > > Mitigation

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

t_uri. The above-quoted mitigations were > introduced to address these issues. Understood; thanks. -Ben > > > > On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk wrote: > > > It is not too late to add to the security considerations. > > > > It seems that the new ap

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

It is not too late to add to the security considerations. It seems that the new application/oauth.authz.req+jwt media-type is helpful in this regard, in that if an AS can require that content-type from dereferencing the request_uri, then seeing anything else indicates that the request was bogus (o

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

On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote: > > On 14/01/2020 19:20, Takahiko Kawasaki wrote: > > Well, embedding a client_id claim in the JWE header in order to > > achieve "request parameters outside the request object should not be > > referred to" is like "putting the c

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

On Wed, Jan 15, 2020 at 08:12:52PM -0800, Benjamin Kaduk wrote: > I'm only the irresponsible AD here, but I expect that you would be welcome > (nay, encouraged!) to write up a clear explanation of why the current > (post-IESG) formulation is bad, what a better formulation should

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

I'm only the irresponsible AD here, but I expect that you would be welcome (nay, encouraged!) to write up a clear explanation of why the current (post-IESG) formulation is bad, what a better formulation should be, and why. This would presumably also include some justification for how the better fo

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 >

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

On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote: > To be clear, I’m not saying we suggest a particular form, and I agree that we > shouldn’t specify that “it’s a JWT” or something of that nature. But if we > call the result of PAR “thing X” and the target of request_uri “thing X” in

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

On Tue, Dec 17, 2019 at 09:12:26PM +, Richard Backman, Annabelle wrote: > > That's a pretty strong statement :) > > One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is not > used at all, just that it is not universal and comes with real, practical > tradeoffs that may n

Re: [OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer

On Thu, Nov 28, 2019 at 12:12:54AM +, Mike Jones wrote: > Please also add these WGLC comments that a Microsoft Azure Active Directory > (AAD) developer asked me to convey: > > > 1. In 4.12, "Authorization servers MUST determine based on their risk > assessment whether to issue refresh to

Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

g access > to the cloud storage of Alice. As the attacker is using the client > (through the clients' website), he now gets access to these files > (stored at the RS). > > Please let me know if you have any other questions. > > Best regards, > Pedram > > > On

Re: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

Hi Pedram, On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote: > > Also, for this or the next version of this document, the Cuckoo's Token > attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should > be addressed. We also discussed this issue extensively at the last O

Re: [OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

On Wed, Nov 20, 2019 at 03:40:34AM +, Mike Jones wrote: > I did a complete read of > draft-ietf-oauth-security-topics-13. > My review comments follow, divided into substantive and editorial sections. > > SUBSTANTIVE > [...] >

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

On Fri, Oct 25, 2019 at 10:02:41AM -0400, Rifaat Shekh-Yusef wrote: > You might want to look at RFC7239, which is trying to address the issue of > the loss of information by proxies. > https://tools.ietf.org/html/rfc7239 > > The document does not have a parameter to carry the client certificate >

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

On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote: >I also agree. Would it be possible to get this pushed to http or tls? It >would be more appropriate there, and very helpful to have a general spec >for this. I think it's possible to get such work done in one of those plac

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

Just on one narrow point: On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote: > On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt > > Open: How would one implement sender constrained access tokens in that > > case? I’m asking since the receiving RS obviously has no access to the > >

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-jwt-bcp-07: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

On Fri, Oct 11, 2019 at 08:17:07AM +0200, Ludwig Seitz wrote: > On 10/10/2019 17:02, Justin Richer wrote: > > They are in that registry as the “token endpoint response” error codes. > > RFC8628 adds new ones. > > > > I think that 6749 failed to put in the base ones. > > > > — Justin > > That wo

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

On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote: > * Last but certainly not least is the restriction that the current > version places on disallowing of the introspection JWT response as an > access token. This is done in numerous places (the note in section 5, > 8.1, etc.). I unders

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

On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote: > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk wrote: > > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > > > Thanks Ben, for the review and non-objectional ballot. > > > > &

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

On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote: > Thanks Ben, for the review and non-objectional ballot. > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ba

[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-resource-indicators-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-mtls-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

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

On Fri, Aug 23, 2019 at 03:07:43PM -0600, Brian Campbell wrote: > Thanks for the responses Ben. More inline below with stuff that warrants no > further discussion snipped out. > > On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk wrote: > > > > > But it's possib

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

On Wed, Aug 21, 2019 at 03:21:23PM -0600, Brian Campbell wrote: > Thanks Ben, I attempt (over the course of many hours) to respond to your > comments and discuss your discuss inline below. > > On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker < > nore.

[OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-mtls-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote: > > > > > >> — Section 1.1 — > > >> Given the extensive discussion of impersonation here, what strikes me as > > >> missing is pointing out that impersonation here is still control

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote: > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba wrote: > > > >> — Section 6 — > > >> Should “TLS” here have a citation and normative reference? > > > > > > I didn't include an explicit reference here because TLS is transitively > > ref

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

Just on one point... On Thu, Jul 18, 2019 at 02:06:10PM -0700, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-token-exchange-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addres

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote: > On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk wrote: > > > > > > Not to my recollection. I'm honestly not even sure what an array would > > mean > > > for "may_act". Do you m

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

On Sat, Jul 06, 2019 at 08:59:30AM -0400, Brian Campbell wrote: > Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more > detail is inline below. > > > On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker < &g

[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-token-exchange-17: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

  1   2   >