Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

Following up on this topic ... On Wed, May 1, 2013 at 2:12 PM, Dick Hardt wrote: > "iss" and "aud" would be optional parameters in a JWE. These parameters > are in the payload, but since it is encrypted, the payload must be > decrypted before they can be r

Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

rypted payload > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Dick Hardt > *Sent:* Tuesday, May 28, 2013 9:34 AM > *To:* O Auth WG > *Subject:* Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header >

Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

anner are > replicated as Header Parameter values in the JWT.” > > ** ** > > -- Mike > > ** ** > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Dick Hardt > *Se

Re: [OAUTH-WG] Unclear parts in OAuth 2.0 specification

On Fri, Aug 30, 2013 at 3:41 PM, Martin Ždila wrote: > Hello > > There are some unclear parts in OAuth 2.0 specification. > > *1.* In 4.3. (B) there is following statement: > >When making the request, the client >authenticates with the authorization server. > > > In 4.3.2 there is followin

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

This change is appropriate and reflects the intent of the statement. On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". > > -- > You may review the

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

My bad, sorry. On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt wrote: > +1 > > Phil > > > On Feb 4, 2014, at 8:33, John Bradley wrote: > > > > The text in 10.16 is correct. > > > > This is a security consideration that has caused serious problems for > Facebook and other implementers. > > > > In the

Re: [OAUTH-WG] Returning tokens directly to a human user

If you are interested in how others have done a similar flow, you could look at how smart TVs supporting Netflix and Amazon are authorized. On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin wrote: > Hi All, > > We might have a requirement to support a case where AS returns an access > token direc

Re: [OAUTH-WG] Legal Notice on RFC 6749 - The OAuth 2.0 Authorization Framework

I'm not the right person to respond to you. On Sat, Mar 21, 2015 at 12:18 AM, wrote: > > Dear. Mr. Hardt > Your committee for this RFC, and as a result, this RFC is infringing at > least one of our patents, namely, US8972590. > > I would like to further discuss this matter and see how we can set

[OAUTH-WG] Tx Auth BOF agenda items

Hey OAuthers As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday Afternoon, I'm gathering who would be interested in making presentations, and how much time you would like. /Dick ___ OAuth mailing list OAuth@ietf.org https://www

Re: [OAUTH-WG] Tx Auth BOF agenda items

eed > 20 min. > > best regards, > Torsten. > > > On 28. Oct 2019, at 16:39, Dick Hardt wrote: > > > > Hey OAuthers > > > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM > Monday Afternoon, I'm gathering who woul

Re: [OAUTH-WG] [Txauth] Tx Auth BOF agenda items

My understanding was it was transaction authorization. (it is unfortunate that authorization and authentication both start with 'auth' in english - 'authN' and 'authZ' are preferred to 'auth' IMHO) On Mon, Oct 28, 2019 at 10:55 AM Kyle Rose wrote: >

Re: [OAUTH-WG] Tx Auth BOF agenda items

Unclear what I was smoking when I said when the BoF was. It is at 13:30-15:30 per https://datatracker.ietf.org/meeting/106/agenda Sorry for any confusion. On Mon, Oct 28, 2019 at 8:39 AM Dick Hardt wrote: > Hey OAuthers > > As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:

Re: [OAUTH-WG] Tx Auth BOF agenda items

> – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Dick Hardt < > dick.ha...@gmail.com> > *Date: *Monday, October 28, 2019 at 8:41 AM > *To: *"oauth@ietf.org" , "txa...@ietf.org" < > txa...@

[OAUTH-WG] Interest in Reciprocal OAuth?

Hello OAuth people Before I tune up the Reciprocal OAuth document per feedback, I'm checking to see who is interested in the specification, and who is considering deploying. Alexa had the requirement originally, but I no longer work there, and I have not seen any input from them. Latest draft ..

[OAUTH-WG] Tx Auth BOF agenda

Hello Everyone, see agenda below: Monday Nov-18-2019 1330 TxAuth Bof Agenda Introduction and Context Chairs 10 min Limitations and Feature Requests Limitations of OAuth Justin 10 min Limitations of OAuth Torsten 5 min Feature Requests Torsten 5 min Feature Requests

[OAUTH-WG] DPoP symmetric key idea

One take away I had from the meeting today, and form the mail list, is the concern of doing asymmetric crypto on API calls. How about if we use the Client's public key to encrypt a symmetric key and pass that back to the Client in the token request response? EG: In response to the token request,

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

On Fri, Nov 22, 2019 at 3:08 PM Neil Madden wrote: > On 22 Nov 2019, at 01:42, Richard Backman, Annabelle > wrote: > > There are key distribution challenges with that if you are doing > validation at the RS, but validation at the RS using either approach means > you’ve lost protection against re

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

and Annabelle’s question about the scope here. > That was the one major thing that struck me during the DPoP discussions in > Singapore yesterday: we don’t seem to agree on what DPoP is for. Some > (including the authors, it seems) see it as a quick point-solution to a > specific use cas

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

+1 On Tue, Dec 17, 2019 at 11:13 AM David Waite wrote: > I support the adoption of PAR > > On Dec 17, 2019, at 5:59 AM, Rifaat Shekh-Yusef > wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed Authorization > Requests document. > https://datatracker.ietf.org/doc/draft-lo

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

I support adoption ᐧ On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle wrote: > I support adoption. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of John Bradley < > ve7...@ve7jtb.com> > *Date: *Monday, January 6, 2020 at 12:05 PM > *To: *

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

+1 to Annabelle's point Different crypto operations should be able to use separate key pairs to allow a separation of duties. ᐧ On Thu, Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle wrote: > The “typ” field helps prevent misrepresentation of a legitimately issued > JWT, but it doesn’t addre

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

OAuth 1.0 assumed the RS and AS were a monolith. OAuth 2.0 separated the RS and the AS. It put them in separate boxes. It also did not define the access token, allowing an implementation to keep them as a monolith, or allow separation of duties. There was no impact on the client, but it was a more

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Torsten Lodderstedt wrote: > > > > Am 10.01.2020 um 18:23 schrieb Dick Hardt : > > > > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect > Provider, and the access token is being defined. These extensions have > assumed all of this functionality

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Yes. Thanks for clarifying. ᐧ On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > You mean additional JWKS URIs, for example? > > Am 10.01.2020 um 19:09 schrieb Dick Hardt : > >  > Perhaps I am misunderstanding what Annabelle wa

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

There are many other factors to resiliency than multiple instances. On Fri, Jan 10, 2020 at 10:30 AM Neil Madden wrote: > > > > On 10 Jan 2020, at 17:22, Dick Hardt wrote: > [...] > > > > As to the suggestion of using a JWT-decryption-microservice, another > goal

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

hat way implementations that expect > just one value of jwks_uri wouldn't have to change. > > Aaron > > > > On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt wrote: > >> Yes. Thanks for clarifying. >> ᐧ >> >> On Fri, Jan 10, 2020 at 10:14 AM Torsten

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

To restate my previous point, we may not be able to change what is currently specified and deployed, but we can for future extensions such as RAR and PAR. To paraphrase Annabelle, this ship may have already sailed. On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt wrote: > The metadata document

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

normal access control > methods you can apply to them without needing to change anything in OAuth.. > > Neil > > On 10 Jan 2020, at 18:50, Dick Hardt wrote: > >  > There are many other factors to resiliency than multiple instances. > > On Fri, Jan 10, 2020 at 10:30 AM Neil

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

it, others may need more > attention. We also need to recognize that we will be ruling out certain > types of deployments, and certain use cases. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Dick Hardt > *Date: *

[OAUTH-WG] RAR & multiple resources?

Torsten / Justin / Brian In my reading of the ID, it appears that there is a request for just one access token, and the authorization_details array lists one or more resources that the one access token will provide access to. Correct? I have heard anecdotally that there is interest in granting ac

Re: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession tokens

3/4 options are at the same time on the same day of the week. More options would be nice! On Mon, Jan 13, 2020 at 9:19 AM Hannes Tschofenig wrote: > Hi all, > > > > at the Singapore IETF meeting we talked about setting time aside for > discussing proof-of-possession tokens. > > > > To schedule a

Re: [OAUTH-WG] RAR & multiple resources?

okens are agreed upon, then it can use the > RAR structure, the Resources parameter, and the Scope parameter all in > parallel again. > > — Justin > > > On Jan 13, 2020, at 8:31 PM, Dick Hardt wrote: > > > > Torsten / Justin / Brian > > > > In my reading

Re: [OAUTH-WG] OAuth Topics for Vancouver

I'd like 5 minutes to see what the interest in Reciprocal OAuth is, if any. On Mon, Jan 20, 2020 at 7:33 AM Rifaat Shekh-Yusef wrote: > All, > > Please, let us know if you have any topics that you would like to present > and discuss in Vancouver. > > Regards, > Rifaat & Hannes > > _

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Rephrasing Annabelle's description to highlight the issue: The AS says "here are the keys to use to verify all of the tokens that *we* have signed" Separating duties in a large system is good cryptographic hygiene, IE, one component signs ID Tokens, another signs access tokens. On Wed, Jan 29,

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

Hey List (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) Given the points Aaron brought up in https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU Does anyone have concerns with dropping the implicit flow from the OAuth 2

[OAUTH-WG] OAuth 2.1: dropping password grant

Hey List (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on) In the security topics doc https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 The password grant MUST not be used. Some background for those interested

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

t; *From:* OAuth *On Behalf Of * Dick Hardt > *Sent:* Tuesday, February 18, 2020 12:37 PM > *To:* oauth@ietf.org > *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant > > > > Hey List > > > > (Once again using the OAuth 2.1 name as a placeholder f

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

Tony: are you ok with dropping password grant? You reference valid use cases. If you think it should continue, would you provide the use cases? ᐧ On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt wrote: > The security topics says MUST. If you want to change that, then that is a > dif

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

n Richer wrote: > >>> There is no need for a grace period. People using OAuth 2.0 can still > do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. > >>> > >>> — Justin > >>> > >>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin

Re: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

I think Mike meant to write "JSON Web Token Best Current Practices" rather than "The OAuth 2.0 Token Exchange specification" On Wed, Feb 19, 2020 at 3:07 PM Mike Jones wrote: > The OAuth 2.0 Token Exchange specification is now RFC 8725 > and BCP 225

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

dds a little friction. (It also adds a > lot of advantages, but it is undeniably more complex). > >>>>> > >>>>> — Neil > >>>>> > >>>>> > >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 4

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

to be updated to refer to OAuth 2.1 rather than OAuth 2.0, OIDC could define the implicit grant type with all the appropriate considerations. ᐧ On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier wrote: > No - please get rid of it. > > ——— > Dominick Baier > > On 18. February 2020

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

gt; — Neil > > > On 21 Feb 2020, at 13:41, Matthew De Haast > wrote: > > I have a feeling that if we had more concise JWT libraries and command > line tools, where using the JWT Bearer grant became a one-liner again then > we wouldn’t be having this conversation. So perhaps

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

e as possible. > > ——— > Dominick Baier > > On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote: > > It looks like there is consensus to remove ROPC for a user -- but that the > password grant is not a bad practice for service accounts. That leads to &g

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

ion for the large population of existing deployments. > > On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt wrote: > >> I'm looking to close out this topic. I heard that Brian and Vittorio >> shared some points of view in the office hours, and wanted to confirm: >> >> +

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

all is sufficient to support Brian’s objective. > > Am 07.03.2020 um 17:06 schrieb Dick Hardt : > >  > How about if we add in a nonnormative reference to OIDC as an explicit > example of an extension: > > "For example, OIDC defines an implicit grant with additional security &

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

Would you clarify what text works Brian? On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell wrote: > Yeah, that works for me. > > On Sat, Mar 7, 2020, 9:37 AM Dick Hardt wrote: > >> Brian: does that meet your requirements? >> >> If not, how about if we refer to OIDC a

Re: [OAUTH-WG] Corona Virus and Vancouver

I will not be attending in-person. ᐧ On Mon, Mar 9, 2020 at 11:35 AM Daniel Fett wrote: > Hi all, > > can we do a quick roll call on who is coming or not coming to Vancouver? > > For me, at the current point in time, it depends on whether a significant > portion of the working group is attending

Re: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec

Hi Mike I like where you are going with this, but what do we mean when we say OAuth 2.0? Is it RFC 6749? What is the OAuth 2.0 set of protocols? OAuth 2.1 includes features that are not in RFC 6749, so it is not a subset of that specification. ᐧ On Sun, Mar 15, 2020 at 2:34 PM Mike Jones wrote:

Re: [OAUTH-WG] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

fitably be factored into another specification so that > the new features can be used either with OAuth 2.0 and OAuth 2.1? That > might make the resulting messaging to developers much clearer. > > > >Thanks, > >

[OAUTH-WG] OAuth 2.1 - IANA Considerations

Please ignore the IANA Considerations section of the draft. https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#name-iana-considerations There are no new IANA registrations, which is what this section should state. Apologies for any confusion. /Dick ᐧ _

Re: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec

e create. Please make it a goal to remove uncertainty and > sources of speculation wherever possible. > > > > Thanks again for the useful discussion. > > > >-- Mike > > > > *From:* Dick Hardt > *Sent:* Monday, March 16, 2020 8:36 AM > *

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

Minimizing market confusing is an objective of the OAuth 2.1 draft. Given you are one of the people explaining to the market, your suggestions are of interest and welcome! On Wed, Mar 18, 2020 at 6:03 AM Jared Jennings wrote: > Perfect, and really good info! but most people, if we need to worry

Re: [OAUTH-WG] IETF 107 Virtual OAuth Sessions

WFM Would you resend the conferencing information again? On Thu, Mar 26, 2020 at 1:04 PM Hannes Tschofenig wrote: > Hi all, > > > > Rifaat and I had a chat about the virtual interim meetings. > > We decided to schedule 6 one-hour-long sessions with 2 topics per session. > > > > Here is the list

Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1

Francis We had a long discussion on this topic earlier this year: https://mailarchive.ietf.org/arch/msg/oauth/mG6tkmXSOxwakC0184snKCGxfSE/ On Wed, Apr 8, 2020 at 3:25 PM Francis Pouatcha wrote: > Hello Aaron, > > Deprecating Resource Owner Password Credentials Flow (Direct Grant) > without re

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

Why does the "sub" need to be required? An access token is to prove authorization. The RS may not need "sub" to constrain fulfilling the client request. For example, it the access token has the same properties as a movie ticket, the RS does not need to have any identifier for who purchased the mo

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

t;>> particular key. >>> >>> If sub is required, then this profile is limited in use to cases where >>> user identifiers are part of the system, and there will be situations in >>> which it’s not appropriate to use this profile for access tokens. If that’s >&

Re: [OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

Brian: many, many thanks for all the feedback! I did a quick skim of your comments, and will address the first and last ones. On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell wrote: > Been working on this on and off for a while now (it's not exactly short at > 80+ pages, various other priorities,

[OAUTH-WG] OAuth 2.1 - require PKCE?

Hello! We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce solves some of the issues that PKCE protects against. We think that most OpenID Connect implementations also support OAuth 2.0, and henc

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

hat it says about servers. My point is that OAuth 2.1’s >> requirements on *clients* should match those in the security BCP and not >> try to go beyond them. >> >> >> >>-- Mike >> >> >&g

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

cs now to prevent ongoing > confusion and interop problems that would otherwise result. Let me know > when you’re ready to incorporate them into the spec text. > > -- Mike > > *From:* Aaron Parecki > *Sent:* Thursday, May 7,

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

On Fri, May 8, 2020 at 12:42 PM Aaron Parecki wrote: > > FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is > OAuth 2.0 with best practices. > > The line there is kind of fuzzy. The objective is not to introduce new > concepts, however there are some changes defined that are

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

x27;t benefit from PKCE is if > they are also confidential clients. Public client OIDC clients still need > to do PKCE even if they check the nonce. > > > > OpenID Connect servers working with confidential clients still benefit > from PKCE because they can then enforce the authorization

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

ou’re willing to remove the “replaces 6749” clause from > the draft, then there would be no perception problem, as it would be clear > that adoption of 2.1 would be voluntary, just like the other extension > specs. > > > > *From:* Dick Hardt > *Sent:* Sunday, May 10, 2020 12:38

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

; 2.0 clients (i.e., the vast majority of them). > > I think we can have a 2.1 spec that says clients and servers MUST support > PKCE without this hard-fail clause. Otherwise I can’t see how we’d ever > ship with 2.1-compliance enabled out-of-the-box. > > — Neil > > On 10 May

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

OAuth 2.0 was incompatible with > OAuth 1.0 by design. > > > > *From:* Dick Hardt > *Sent:* Sunday, May 10, 2020 12:58 PM > *To:* Mike Jones > *Cc:* Torsten Lodderstedt ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Just

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

r an AS to claim 2.1 compliance? > > On 10 May 2020, at 21:19, Dick Hardt wrote: > > Is there a reason why a server can not support both OAuth 2.0 and OAuth > 2.1? The version supported could be dependent on the client id, ie older > clients could still be OAuth 2.0, and newer clients w

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

dds is a potential incompatibility with > no security gain? (Given that servers and clients can already support PKCE > if they wish). > > All I can see this doing is delaying adoption of 2.1 by ASes. > > — Neil > > > On 10 May 2020, at 21:35, Dick Hardt wrote: > > Sou

Re: [OAUTH-WG] [EXTERNAL] Re: proposed resolution for PKCE in OAuth 2.1

Hi Mike I'm not sure what you are suggesting as it is not clear if you are describing the client or the server. It also seems like you are suggesting we create a new signal for requiring PKCE. Would that be optional in OAuth 2.1, or is it required? What would happen to existing clients? /Dick On

Re: [OAUTH-WG] Downgrade attacks on PKCE

Mike: what are your thoughts on the options? ᐧ On Sat, May 30, 2020 at 4:39 AM Neil Madden wrote: > We (ForgeRock) already support solution 1 as a configuration option, but I > prefer solution 2 and have raised a ticket for us to implement it. For us > at least it’s a trivial fix and seems more

Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108

+1 On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef wrote: > All, > > As you know, IETF108 will be online, and based on the discussion during > the last interim meeting series, our plan is to schedule another series of > these meetings for the OAuth WG. > Based on the WG feedback, the plan is

[OAUTH-WG] OAuth 2.1-03 - WG adoption?

Aaron, Torsten, and I -- with some help from Daniel -- have created a new version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption call (assuming the updated charter). Here is the doc: https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03 Here is a link to the diff from -02:

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

Thanks Sascha and Vladimir for the feedback! Sascha: did you have a concern with the document being adopted by the WG? ᐧ On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch wrote: > Hi all! > > Here is the rest of my feedback. At the end I also included a list of > typos and the summary of changes

Re: [OAUTH-WG] Rotating client secret

I don't know of any discussion for client secret rotation. Another way to solve your problem could be to raise it up a layer. Admin B generates a one time use URL that is sent to Admin A. Admin A visits the URI and obtains the client_id and client_secret. On Mon, Jul 13, 2020 at 2:35 PM Amarend

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

+1 On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef wrote: > All, > > This is a *call for adoption* for the following *OAuth 2.1* document as a > WG document: > https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html > > Please, provide your feedback on the mailing list by *July 29th.* > > R

Re: [OAUTH-WG] Namespacing "type" in RAR

Hey Justin, glad to see that you have aligned with the latest XAuth draft on a type property being required. I like the idea that the value of the type property is fully defined by the AS, which could delegate it to a common URI for reuse. This gets GNAP out of specifying access requests, and enab

Re: [OAUTH-WG] Namespacing "type" in RAR

tf.org/html/rfc7519#section-4.2 > > What I’m proposing is that if you think it’s going to be a general-purpose > type name, then we recommend you use a URI as your string. And beyond that, > that’s it. It’s up to the AS to figure out what to do with it, and RAR > stays out of it. >

Re: [OAUTH-WG] Namespacing "type" in RAR

a smaller ecosystem. And this is yet another > reason that we define “type” as being a string to be interpreted and > understood by the AS — so that an AS that wants to work this way can do so. > > — Justin > > PS: thanks for pointing out the error in the example in XYZ, I’ll fi

Re: [OAUTH-WG] Namespacing "type" in RAR

ou brought that up and then described the process that the AS would > take to do so. I have said from the start that the use of a URI is for name > spacing and not for addressing content to be fetched, so I’m confused why > you think I intend otherwise. > > — Justin > >

Re: [OAUTH-WG] Namespacing "type" in RAR

ot required for the RAR spec. I’m against requiring > the value to be a URI and against requiring the AS to process that URI *as > a URI* at runtime. Anything that an AS wants to do with the “type” value, > including providing additional tooling and validation, is up to the AS and > outsi

Re: [OAUTH-WG] Namespacing "type" in RAR

An explanation of the issues in Unicode can be found here: https://en.wikipedia.org/wiki/Unicode_equivalence#Character_duplication On Tue, Jul 21, 2020 at 10:03 AM Dick Hardt wrote: > > The following are the same URI, but are different strings: > > “https://schema.example.org/

Re: [OAUTH-WG] Namespacing "type" in RAR

any requirements on > canonicalization for these values. > > — Justin > > On Jul 21, 2020, at 1:03 PM, Dick Hardt wrote: > > > The following are the same URI, but are different strings: > > “https://schema.example.org/v1” > “HTTPS://schema.example.org/v1

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

One of the constraints of the OAuth 2.1 document that aligned the WG was it would have no new features. I'd recommend a separate document for the cookie bearer token feature. ᐧ On Thu, Jul 30, 2020 at 12:15 PM Jim Manico wrote: > Yea to cookie configuration suggestions! > > I suggest SameSite=

Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

Dev’s now need to read 20 standards to get OAuth2 basics... > and that’s a barrier to entry. > > -- > Jim Manico > @Manicode > > On Jul 30, 2020, at 3:21 PM, Dick Hardt wrote: > >  > One of the constraints of the OAuth 2.1 document that aligned the WG was > it would h

Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-1-00 (The OAuth 2.1 Authorization Framework)

Karsten / Christian: thank you for reviewing the draft and all of your feedback. Greatly appreciated! Responses inline ... if no comment, I (or another author) will have to review to respond. On Thu, Aug 6, 2020 at 3:48 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhau...@hackmanit.de> wrote:

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

In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in

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

I'm supportive of this work. It is not clear that it is in the charter of the OAuth WG. On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan wrote: > Hi Neil, > > I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how > to go about it tho since JOSE is a concluded WG. > > Out of cur

[OAUTH-WG] office hours / meeting this week?

Are either of these happening tomorrow? If so, what is the WebEx link? Thanks! ᐧ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt wrote: > Hi Denis, > > > On 25. Aug 2020, at 16:55, Denis wrote: > > > The fact that the AS will know exactly when the introspection call has > been made and thus be able to make sure which client > > has attempted perform an access to that RS

Re: [OAUTH-WG] WGLC Review of PAR

I think one-time use may be overly restrictive, and I don't think it is the property that we actually want. Give the request URI is in a redirect from the browser, there is a good chance of a race condition where the same browser request is made more than once, for example, while the browser is lo

Re: [OAUTH-WG] WGLC Review of PAR

e and continue the session as appropriate. > > None of this is in conflict with “one time use”, in my view, since you’re > actively detecting the session and source of the value. > > — Justin > > On Aug 26, 2020, at 6:16 PM, Dick Hardt wrote: > > I think one-time use may b

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

this is the JWT Access Token spec. There are plenty of others. > > The downsides of using an Introspection Endpoint should be described in > the Privacy Considerations section. > > -- Mike > > From: OAuth On Behalf Of Di

Re: [OAUTH-WG] third party applications

The driver in my opinion for first-party use of OAuth is to separate the trust domains so that the application is scoped in what it can do vs an application that has full access to all resources. I agree that third-party can indicate that internal use does not apply. How about the following? Th

Re: [OAUTH-WG] third party applications

nstraint on the kind of applications OAuth can > be used for. I don’t see how this governs the protocol design. > > > On 28. Aug 2020, at 15:29, Dick Hardt wrote: > > > > The driver in my opinion for first-party use of OAuth is to separate the > trust domains so that the app

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

If this implication is not acceptable, implementers can > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > On Aug 27, 2020, at 12:15 PM, Dick Hardt wrote: > > Here is a crisper revision. > > Impl

Re: [OAUTH-WG] WGLC Review of PAR

gt; > Since parts of the request content, e.g. the "code_challenge" >parameter value, is unique to a certain authorization request, > the client SHOULD use the "request_uri" only once. > > I also would move this text to section 4. > > > On 27. Aug

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

about the privacy implications of using >> an Introspection Endpoint. That’s why it’s preferable to not use one at >> all and instead directly have the Resource understand the Access Token. >> One way of doing this is the JWT Access Token spec. There are plenty of >> other

Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07

Denis The objective of this document is to standardize the token the AS shares with the RS. It is not to standardize how the client can read the token. Just because the user is using the client, that does not mean the user wants the client to see any claims about themselves. Letting the client se

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

+1 KISS ᐧ On Tue, Sep 8, 2020 at 3:55 PM John Bradley wrote: > +1 > On 9/8/2020 7:45 PM, Brian Campbell wrote: > > Indeed there are cases, as you point out, where the key might be knowable > to the server via some other means, which makes the "jwk" header in the > DPoP proof not strictly necess

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

That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm not sure where you landed given your last sentence) ᐧ On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell wrote: > Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit > and it took some time to gather my th

  1   2   3   4   5   6   >