Re: [OAUTH-WG] updated Distributed OAuth ID

y are you asking? > > > On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> >> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >> >> In your examples, are these the same AS? >> >> >> yes >>

Re: [OAUTH-WG] updated Distributed OAuth ID

ed UX. > > Am 24.07.2018 um 22:21 schrieb Dick Hardt : > > I'm trying to understand the use case. > > It still is vague. Are you saying that each of these is run by a > different entity, but all trust the bank as the authorization server to > manage if the user has granted pe

Re: [OAUTH-WG] updated Distributed OAuth ID

On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Dick, > > Am 19.07.2018 um 15:46 schrieb Dick Hardt : > > I think any scenario with multiple resource servers relying on the same AS >> for authorization where the client act

Re: [OAUTH-WG] updated Distributed OAuth ID

In your examples, are these the same AS? On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: > Hi Dick, > > > Am 23.07.2018 um 00:52 schrieb Dick Hardt : > > > > Entering in an email address that resolves to a resource makes sense. It > would seem that even

Re: [OAUTH-WG] updated Distributed OAuth ID

On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Dick, > > > >> >> Section 3: >> Don’t you think it could be a useful information to have the resource URI >> available in the authorization flow?I would assume it could have some >> additional meaning to

Re: [OAUTH-WG] updated Distributed OAuth ID

consumed within an > origin. This would actually make redundant/supplemental the AS additions > defined within this spec (resource/origin request parameter, ‘aud’ > introspection response member) > Token binding solves part of the resource constrained access token requirement, but

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

I'm supportive. :) On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'Distributed OAuth' document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: >

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

William: there was discussion in the meeting about the PoP document using "resource" rather than "aud" On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones < Michael.Jones=40microsoft@dmarc.ietf.org> wrote: > Microsoft’s Azure AD OAuth server has used the resource= parameter since > at least 2012 to

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

I support adoption of this document. On Thu, Jul 19, 2018 at 4:54 PM, John Bradley wrote: > > > I accept the adoption of this document. > > > > Sent from Mail for > Windows 10 > > > > *From: *Rifaat Shekh-Yusef > *Sent: *Thursday, July 19, 2018

Re: [OAUTH-WG] OAuth WG draft agenda

Besides being the oddness that session I happens after session II ... looks ok! On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef wrote: > The following is a draft agenda for next week. > Please, let us know if you have any comments. > > Regards, > Rifaat & Hannes > > > Web Authorization

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

re-submit the document with a new filename that matches >> the updated title. >> >> Ciao >> Hannes >> >> >> On 01/16/2018 03:39 PM, Dick Hardt wrote: >> > I have made changes based on feedback on the call this morning. Updated >> > version

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

, 2018 at 11:25 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > Brian > > *grant type* > Thanks for the grant type pointers. > > *client_id* > The reciprocal flow by its nature is part of a code_grant flow, and I > expect that party A and party B can be reversed. G

Re: [OAUTH-WG] Call for agenda items

ng a > f2f interim meeting for OAuth is possible we have not discussed this so > far. > > > > Ciao > Hannes > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *n-sakimura > *Sent:* 18 April 2018 07:34 > *To:* Dick Hardt; n-sakimura > *Cc:* o

Re: [OAUTH-WG] Call for agenda items

as part of the OAuth working group is that > you involve other interested parties to the discussion, and that you do not > have to repeat your private conversations later again on the mailing list.. > > That’s pretty convincing to me ;-) > > > > Ciao > > Hannes > >

Re: [OAUTH-WG] Call for agenda items

I'd like to coordinate a side meeting with Nat, Brian, myself and other interested parties in Montreal to discuss Distributed OAuth. If we have two meetings, I'd like a timeslot in the second to summarize the side meeting and discuss next steps (if any). Separately, I'd like a time slot for an

Re: [OAUTH-WG] Call for agenda items

organize a conference call on > that topic if you and the group think that no such meeting is necessary. > > > > *From:* Dick Hardt [mailto:dick.ha...@gmail.com] > *Sent:* 18 April 2018 16:29 > > *To:* Hannes Tschofenig > *Cc:* n-sakimura; oauth > *Subject:* Re: [OAUTH-WG]

Re: [OAUTH-WG] Call for agenda items

mbined draft. > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > ---

Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth

As the author, I support the adoption. Do we have consensus now? On Tue, Apr 17, 2018 at 1:18 PM, William Denniss wrote: > +1, I support the adoption of this document. > > I've encountered this problem in the wild for account linking scenarios, > and I think it would be

Re: [OAUTH-WG] AS Discovery in Distributed Draft

There is a requirement in Distributed OAuth for the client to locate one or more AS metadata files for a given resource. On Tue, Nov 6, 2018 at 12:35 PM David Waite wrote: > Is there a need for a client to understand the identity of an > authorization server? > > This would seem to mean that

[OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant

Omar As promised, I have reviewed the ID[1] you posted. I'm confused in the Motivation by the references to authentication, as OAuth is about authorization. Perhaps you can post to the list the use case you are trying to solve for? I can infer aspects, but don't fully understand it. >From what

Re: [OAUTH-WG] AS Discovery in Distributed Draft

George: in the WG meeting we discussed this topic of where to put the discovery information. No one at the meeting advocated for using Link response (Nat was the one who was advocating for this). Many others preferred using the www-authenticate header similar to how you propose. On Thu, Nov 8,

Re: [OAUTH-WG] AS Discovery in Distributed Draft

Phil, would you clarify what you are suggesting? I'm unclear if you are disagreeing with George or not. On Thu, Nov 8, 2018 at 4:28 AM Phil Hunt wrote: > I’m seeing broader need for discovery of OAuth infrastructure for APIs in > general now that APIs are being deployed by many parties: > *

Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant

> untrusted device in an untrusted network. I looked for a way to > authenticate the requests from the device to AS. > Does it make more sense now? > > On Thu, Nov 8, 2018 at 12:42 PM Dick Hardt wrote: > >> Omar >> >> As promised, I have reviewed the ID[

Re: [OAUTH-WG] questions on Seamless OAuth 2.0 Client Assertion Grant

e blog post - > https://blog.solutotlv.com/userless-mobile-authentication/ > > Does this help? > > Also, thank you for your time and feedback. I appreciate it! > > On Fri, Nov 9, 2018 at 1:54 AM Dick Hardt wrote: > >> More detail on the scenario would help. >> >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

; In order to avoid these issues, Clients SHOULD NOT use the response >>> type „token". The response types >>> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the >>> issued access tokens are not >>> > sender-constrained. >&g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I disagree. Existing deployments that have not mitigated against the concerns with implicit should be ripped up and updated. For example, at one time, I think it was Instagram that had deployed implicit because it was easier to do. Once the understood the security implications, they changed the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1 While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic. How about we recommend against using implicit alone?

Re: [OAUTH-WG] OAuth WG Sessions in Montreal

I will update the Reciprocal OAuth draft and provide an update. I will be there in person. On Wed, May 29, 2019 at 3:35 PM Vittorio Bertocci wrote: > I will publish an update of the JWT profile for ATs by then. If there is a > slot available, I would love to discuss it. I will attend in person

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

+1 On Mon, Apr 8, 2019 at 10:07 AM Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens' > document following the positive feedback at the last IETF meeting in Prague. > > Here is the document: >

Re: [OAUTH-WG] Info on how to implement a server

On Sun, Aug 18, 2019 at 2:29 PM Salz, Rich wrote: > Not to be pedantic, but adding OAuth support is a mechanism in support > of a goal. What's the end goal? > > * Letting third party apps use the datatracker API? > * Letting people sign in to other apps with a datatracker

Re: [OAUTH-WG] Info on how to implement a server

What is the goal? On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich wrote: > Thanks for the links, folks. I’m aware, and sorry for my sloppy > terminology. > > > > Imagine a service where anyone with a valid identity is authorized. There > are many of these on the net. Collapsing authentication to

Re: [OAUTH-WG] Info on how to implement a server

That sounds like a means to an end. Do you want to enable applications to call datatracker APIs? On Sun, Aug 18, 2019 at 2:05 PM Salz, Rich wrote: > As I said at the start of the thread: I want to add OAUTH support to the > datatracker. > > > > *From: *Dick Hardt > *Dat

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

t@dmarc.ietf.org>: >> >>> How about the University in Gjovik ? >>> >>> Get Outlook for Android <https://aka.ms/ghei36> >>> >>> -- >>> *From:* OAuth on behalf of Daniel Fett < >>&

Re: [OAUTH-WG] Question regarding RFC 7592

hear why you’d say that) — it’s an API you > can call to manage a client’s registration data over time. Sounds like an > RS, if you ask me. > > — Justin > > On Sep 15, 2019, at 1:05 AM, Dick Hardt wrote: > > Curious why the client management API uses bearer tokens rather than JWTs >

Re: [OAUTH-WG] Question regarding RFC 7592

Curious why the client management API uses bearer tokens rather than JWTs per RFC 7523 for the client to authenticate. The client management API seems more similar to a token endpoint than a resource. ᐧ On Fri, Sep 13, 2019 at 12:08 PM Justin Richer wrote: > Travis has this correct — the

Re: [OAUTH-WG] Question regarding RFC 7592

he job directly instead. At least, that was the thinking, and > I still agree with that line of thought today even with its quirks. > > — Justin > > On Sep 17, 2019, at 12:40 AM, Dick Hardt wrote: > > The registration supports the client having a jwks, so if the client > prov

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Jones ( > michael.jones=40microsoft@dmarc.ietf.org) wrote: > > I'm not aware of any conflicts for any of the three sets of dates. > > -- Mike > > -Original Message- > From: OAuth On Behalf Of Aaron Parecki > Sent: Thursday, July 25, 2019 4:07 PM > To: Dick Har

Re: [OAUTH-WG] Transaction Authorization

Hi Neil, I agree that an access token that is usable across resources is problematic. How are you thinking multiple access tokens would be returned? Why do you think the request needs to return multiple tokens rather than making a separate request for each token? That would seem to simplify the

Re: [OAUTH-WG] Transaction Authorization

Hey Justin A few use cases that highlight how the world is different now than it was when OAuth 2.0 was developed would help participants understand why changes are needed, and also provide a reference for comparing and contrasting different approaches. One of my first comments is why the client

Re: [OAUTH-WG] Transaction Authorization

l 2019, at 22:22, Dick Hardt wrote: > > Hi Neil, I agree that an access token that is usable across resources is > problematic. > > How are you thinking multiple access tokens would be returned? > > > Well there are lots of possible ways, e.g.: > > { > "

[OAUTH-WG] Dinner tonight (Tuesday)?

Anyone not going to the social that wants to get dinner? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

+1 to July / August. Nicer weather in the north then. =) On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett wrote: > Hi all, > > it seems like there is a rough consensus on having the next OAuth Security > Workshop in Trondheim, Norway. We will therefore start with the planning. > > After checking

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04

Brian / George: thanks for the detailed critique of the draft -- much appreciated. Given all the feedback, it is clear the draft needs more work before submitting to the IESG. Unfortunately, it will be a few weeks before I have time to review and respond to your comments. ᐧ On Fri, Sep 6,

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

If I understand the proposal correctly, the request URI is opaque to the client. Correct? If so, why not just treat it as an opaque string? If I were implementing the protocol, I would have the blob be a signed token so that I could verify the integrity before making a database call. It much

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

> recommend implementers use. > > In the interest of keeping the specs in sync I think it makes sense to > keep it a URN for this spec, but with more of an explanation as to why? > > Dave > > On Fri, 27 Sep 2019 at 19:22, Dick Hardt wrote: > >> If I understand th

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

[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

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

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: > On Mon, Oct 28, 2019 at 11:39 AM Dick Ha

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.

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] 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: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

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 case. Others see it as a general PoP mechanism. > > >

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106

I'd like a slot to provide an update on Reciprocal OAuth. ᐧ On Fri, Oct 4, 2019 at 2:12 PM Brian Campbell wrote: > Hello chairs, > > I'd like to request some agenda time to present on: > https://tools.ietf.org/html/draft-fett-oauth-dpop > > Thank you, > Brian > > On Fri, Oct 4, 2019 at 3:09 PM

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

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

> 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 removing it is an &g

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

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 placeholde

[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

[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

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

her 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 40mi

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

so adds a > lot of advantages, but it is undeniably more complex). > >>>>> > >>>>> — Neil > >>>>> > >>>>> > >>>>>> On 21 Feb 2020, at 13:41, Matthew De Haast 40coil@dmarc.ietf.org> wrote: &

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

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 Lodd

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 docum

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: [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: *

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

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

[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

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

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

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

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 functional

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] RAR & multiple resources?

ss tokens 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] 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] OAuth 2.1 - drop implicit flow?

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: >> >> + Remove implicit flow from

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

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

;> 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 >>&g

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

[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] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

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

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

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

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

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 >> >> >> >> *From:* Aaron Pare

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

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 wou

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] [EXTERNAL] Re: OAuth 2.1 - require 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 code injection > protectio

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

it adds 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: > > Sounds l

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

u’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 PM &

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

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

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

at 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

<    1   2   3   4   5   >