Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

On Fri, Dec 28, 2018 at 03:55:15PM -0700, Brian Campbell wrote: > > The observed behavior of the browsers surveyed seems logical and rather > reasonable (and better than the last time I futzed with it). Importantly it > means that for the situation described in the email that started this > thread

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

On Mon, Jan 07, 2019 at 10:21:51AM -0700, Brian Campbell wrote: > I don't honestly know for sure but I suspect that employees of big > corporations will likely have keys/certs on their devices/machines that are > issued by some internal CA and provisioned to them automatically (and in > many cases

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

- I've attempted to reply, as best I can, to your > comments/questions inline below. > > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-oauth-token-exchange-16: Discuss > >

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

On just one narrow point... On Mon, Jan 14, 2019 at 02:28:59PM -0700, Brian Campbell wrote: > > I will say that, in addition to the folks that have pointed out that > renegotiation just isn't possible in some cases, my experience trying to do > something like that in the past was not particularly

Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud

On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > The token-exchange draft defines both the "resource" and "audience" > parameters for use in the context of a > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the > token endpoint. There is a lot of overlap

Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings

On Thu, Mar 14, 2019 at 06:55:38AM -0600, Brian Campbell wrote: > There are icon links for audio and video next to the sessions on the agenda > at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration > is required (but is free for remote participants). See > https://www.ietf.org

Re: [OAUTH-WG] Review of draft-ietf-oauth-signed-http-request-03

Hi Mike, Thanks for doing this review; just to confirm one point... On Tue, Mar 26, 2019 at 02:35:47PM +, Mike Jones wrote: > > 3. "Note to WG" - I suspect that this wouldn't get past the IESG without > crypto agility. A parameter probably needs to be introduced to specify the > hash alg

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

Hi Vittorio, On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittorio Bertocci wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have the > su

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

This looks correct to me, so I'll mark it as verified. -Ben On Tue, Apr 09, 2019 at 03:02:46PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC7636, > "Proof Key for Code Exchange by OAuth Public Clients". > > -- > You m

Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution

On Fri, Apr 26, 2019 at 10:51:53AM +, Luca Arnaboldi wrote: > * I spoke with Hannes after the IETF meeting in Prague and he expressed the > need to enhance our formal analysis (as presented at the OAuth Security > Workshop) to verify whether it is necessary to demonstrate possession of the >

Re: [OAUTH-WG] Transaction Authorization with OAuth

On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote: > Hi Sascha, > > I see. I assume every element within the structured scope element to be an > independent scope (value) object and intended to use the name of that object > as kind of content type definition. > > In my last e

Re: [OAUTH-WG] Transaction Authorization with OAuth

On Tue, Apr 30, 2019 at 12:08:32PM +0200, Torsten Lodderstedt wrote: > > > > Am 28.04.2019 um 06:08 schrieb Benjamin Kaduk : > > > >> On Wed, Apr 24, 2019 at 07:08:25PM +0200, Torsten Lodderstedt wrote: > >> Hi Sascha, > >> > >> I see. I as

Re: [OAUTH-WG] draft-fett-oauth-dpop-01 implementation feedback

On Wed, May 01, 2019 at 11:32:40PM -0700, Paul Querna wrote: > Hi all, > HTTP Request Signing > > o "http_method": The HTTP method for the request to which the JWT is > > attached, in upper case ASCII characters, as defined in [RFC7231] > > (REQUIRED). > > > > o "http_uri": The HTTP

Re: [OAUTH-WG] Link relations for authenticating

Hi Evert, On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote: > Hi everyone! > > I've been running into a number of situations where it would have been > beneficial to have a few protocol/media-type agnositic link relation > types for user authentication purposes. > > https://tools.ietf.o

Re: [OAUTH-WG] Off Topic: oauth-bounces

On Tue, May 07, 2019 at 10:46:43AM +0100, Neil Madden wrote: > I notice that a few of my emails to the OAuth WG list have come through with > the From field from “oauth-bounces”: > > From: OAuth On Behalf Of Neil Madden > > Is this normal? I checked my subscription status on mailman and I’m pos

Re: [OAUTH-WG] MTLS vs. DPOP

On Tue, May 07, 2019 at 11:18:21AM -0600, Brian Campbell wrote: > Practically speaking there's the MTLS draft, which has been sent to the > IESG for publication, has commercial and opensource implementations as well > as production deployments, and is referenced by other prospective standards > and

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben -- Forwarded message -- Date: Mon, 15 Dec 2014 12:14:30 -0500 From: Benjamin Kaduk To: kit...@ietf.org Cc: kitten-cha...@tools.ietf.org Subject

[OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth

Hi all, During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt back in December 2013, in http://www.ietf.org/mail-archive/web/kitten/current/msg04488.html . The relevant point here is that sending a scope of "" (the empty string) during the authorizatio

Re: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth

Hi Torsten, On Tue, 24 Mar 2015, Torsten Lodderstedt wrote: > Hi Benjamin, > > in my opinion, your proposal sound reasonable from a protocol perspective. I should clarify that Bill came up with the idea; I just sent the mail. Thank you for reviewing it. -Ben __

Re: [OAUTH-WG] Rate limiting in Dyn-Reg-Management

On Fri, 3 Apr 2015, Justin Richer wrote: > In the current draft of Dyn-Reg-Management > (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 > ) there’s > a clause that’s causing some consternation in the general

[OAUTH-WG] Fwd: Last Call: (A set of SASL Mechanisms for OAuth) to Proposed Standard

Hi all, I just wanted to call attention to this IETF Last Call; there were some changes since the -18 which is the last one that we sent to this list. -Ben -- Forwarded message -- Date: Thu, 30 Apr 2015 14:31:47 -0400 From: The IESG Reply-To: i...@ietf.org To: IETF-Announce Cc:

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4819)

On Thu, 6 Oct 2016, Lars Kemmann wrote: > Ah, you’re right. Thanks! Should I resubmit it? Kathleen can get it edited in-place. -Ben > > > > ~Lars > > > > From: Manger, James > Sent: Wednesday, October 5, 2016 6:07 PM > To: RFC Errata System

Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq

On Tue, Jan 03, 2017 at 05:52:22PM +0100, Denis wrote: > > > *1°. The draft will be unable to move to Draft Standard* > > The Intended status of draft-ietf-oauth-jwsreq is Standards Track. > > RFC 5657 states: Advancing a protocol to Draft Standard requires > documentation of the *interoperati

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

On Mon, Mar 27, 2017 at 03:08:39PM +0200, Denis wrote: > Hi Nat, > > HI. > > > > As pointed out in saag, the OAuth WG is not dealing with ABC attack. > > It is out of scope for now at least. > > A threat along the ABC attack is not mentioned in RFC 6819 : OAuth 2.0 > Threat Model and Security Co

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

On Mon, Mar 27, 2017 at 10:46:41AM +0200, Denis wrote: > You may however continue to progress this document as an individual > contribution. [obligatory note that Denis is not in a position to grant or deny permission to adopt the document as a WG document] -Ben

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

On Fri, Aug 04, 2017 at 03:36:10PM +0200, Denis wrote: > > Before writing an individual draft, there needs to be a general > agreement within the WG to consider such a work item as valuable. Anyone can write an individual draft at any[1] time. Having thoughts specified in a concrete proposed sp

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Just replying on one thing... On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote: > Hi Brian, > > Thanks for the detailed responses. Comments in line below (marked with ***). > > Neil > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell > > mailto:bcampb...@pingidentity.com)> w

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Picking nits, but maybe "established and well-tested X.509 library (such as one used by an established TLS library)", noting that TLS 1.3 has added a new protocol feature that allows for TLS and X.509 library capabilities to be separately indicated (as would be needed if they were organizationally

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

l had with the text in the draft as > informational? Or? I'm honestly not sure if it's okay to cite a blog post > or university paper. > > > <https://www.cryptologie.net/article/374/common-x509-certificate-validationcreation-pitfalls/> > > > > > On Tu

Re: [OAUTH-WG] PoP Key Distribution

On Tue, Jul 03, 2018 at 08:10:52PM +, Mike Jones wrote: > > I believe that the ACE "profile" parameter is typically unnecessary and > not in the spirit of normal OAuth. Configuration information between > OAuth participants is typically configured out of band and/or retrieved > from the AS Di

Re: [OAUTH-WG] ACE - OAuth Synchronization

Hi Hannes, Can you remind me which parameters are being problematic in this regard? I mostly only remember the ace discussions of keyid, recently, so I probably lost track of some relevant bits. Thanks, Ben On Thu, Jul 19, 2018 at 02:34:26PM +, Hannes Tschofenig wrote: > Hi Ben, Hi Ekr, >

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

Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-device-flow-11: 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

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

On Wed, Aug 01, 2018 at 05:16:52PM -0700, William Denniss wrote: > Benjamin, > > Thank you for the feedback. We just posted version 12 which addresses many > of your feedback points. Replies inline. > > On Tue, Jul 24, 2018 at 6:31 AM, Ben

Re: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

On Thu, Aug 02, 2018 at 11:41:05AM -0700, William Denniss wrote: > Alissa, > > Thank you for your review. Replies inline: > > On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper wrote: > > > > > Section 3.3: > > > > "It is NOT RECOMMENDED for authorization servers to include the user > >code in

Re: [OAUTH-WG] Non-repudiation for API requests and responses

On Fri, Aug 31, 2018 at 06:56:34AM +0200, Dave Tonge wrote: [snip] > In Europe we have a number of standards groups who are defining these APIs > on behalf of banks. Unfortunately they are all taking different approaches > to this problem - including the use of a draft that I understand isn't on a

  1   2   >