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

I do recall password flow was only in 6749 to facilitate transition to oauth.. Maybe it is reasonable to consider ending it now. Phil > On Feb 18, 2020, at 1:15 PM, Justin Richer wrote: > > There is no need for a grace period. People using OAuth 2.0 can still do > OAuth 2.0. People using OAu

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

It may be programmatically equiv but from a trust perspective very different. Usually client cred flows are from trusted entities and fixed endpoints. Phil > On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle > wrote: > > ROPC without a client ID or authentication is functionally equi

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

Why not just require service accounts to use mutually acceptable http method of authentication? Eg instead id/password, service acnt client could use mtls auth or http basic or some other method. AFAIK this is already widely done. Is there so much interop value that specifying only the weak

Re: [OAUTH-WG] Corona Virus and Vancouver

I do not plan to attend in person but I will be around. Phil > On Mar 9, 2020, at 11:48 AM, Brian Campbell > wrote: > >  > I plan to be in Vancouver. > > But recognize there's some uncertainty about it all, which was the > inspiration for the closing slide used in the interim just now:

[OAUTH-WG] Privacy Pass - overlaps with OAuth DPOP work?

I noticed this BOF on the IETF virtual conference agenda for today. It seems to cover a lot of areas discussed in the OAuth WG and may be of interest. https://datatracker.ietf.org/meeting/107/session/privacypass Cheers, Phil Hunt @independentid phil.h...@independentid.com ___

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

Mike, The point of 2.1 is to raise the security bar. Yes it adds new MUST requirements. But what about OIDC would break other than required implementation of PKCE to support 2.1? Eg Would additional signaling be required to facilitate interoperability and migration between versions? Would t

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

#x27;t? > >> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt : >> Mike, >> >> The point of 2.1 is to raise the security bar. >> >> Yes it adds new MUST requirements. >> >> But what about OIDC would break other than required implementation of

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

-- Mike > > From: Aaron Parecki > Sent: Wednesday, May 6, 2020 12:29 PM > To: Steinar Noem > Cc: Phillip Hunt ; Mike Jones > ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > I should add that even some OpenID Connect profiles require PKCE,

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

+1 Phil > On May 7, 2020, at 11:50 PM, Daniel Fett wrote: > >  > +1 to all what Aaron said. Thanks for pointing this out! > > We need to address this in the security BCP and this will be a normative > change that affects OpenID Connect Core (just as our current recommendation > on the usag

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

We are not discussing anything new here. We are discussing adoption of best practice. The disconnect appears to be that one dependent standard’s “typical” use (nonces) does not have the ietf consensus as best practice. This lack of consensus needs to be resolved. Phil > On May 8, 2020, at

[OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?

One of the use cases brought up in the ROPC thread mentioned that redirect was hard to do in some cases (like IoT). This reminded me of RFC8628, the OAuth Device Authorization Grant. I mention it because for *some* of the cases who say redirection is hard may be able to use the Device Authz Gran

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

Denis, I agree with Hannes. Speaking as one of the security consideration and threat model authors for OAuth2, a foundational design assumption was always that access tokens are opaque to clients. Even in the case of OIDC they created the id token to be a token defined for the client in the s

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

+1 Phil > On Jun 22, 2020, at 3:16 PM, Mike Jones > wrote: > >  > +1 from me too > > From: OAuth On Behalf Of Torsten Lodderstedt > Sent: Sunday, June 21, 2020 2:42 PM > To: Falk Andreas > Cc: oauth > Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of > IETF108

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

One thing that this thread is overlooking (Hannes and others have mentioned it) is that OAuth is an *authorization* protocol not intended for authentication. OAuth is not really for federation and sharing of claims. The idea is for an authz server to issue short term tokens that contain enou

Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP

Justin Thanks for this. I am pleased the HTTPbis group took this up. It is a multi-WG issue that needs their expertise. I look forward to reading the new draft. Cheers, Phil > On Apr 29, 2021, at 8:34 AM, Justin Richer wrote: > > Many of you will remember an old draft that I was the edito

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Agreed. Most of dyn reg cases we were thinking about occurred because there was a need to register each copy of the same client software. The software statement was intended to allow the registration endpoint recognize software and to fix things like endpoints. Automatic registration of single

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id. I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to. They likel

Re: [OAUTH-WG] MAC Tokens body hash

Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav wrote: > The idea is to drop 'ext' and 'bodyhash' due to being underspecified and > therefore causing more harm than good. I added 'ext' to allow for application > specific data to be included in the signed content. However, the name > suggest

Re: [OAUTH-WG] Auth Code Swap Attack

No. I don't think so. In the new variant the client has to check the returned state to confirm it has not changed or associated with a different user. Previously the authz server had to do the checks. Phil On 2011-08-13, at 21:16, "William J. Mills" wrote: > The defense is the same though,

Re: [OAUTH-WG] MAC Tokens body hash

f someone publishing an I-D with a full syntax and > canonicalization requirements for say, singing an entire request, headers and > all. I feel that would be much better accomplished by defining a new HTTP > authentication scheme. > > > > Philosophically, I think exten

Re: [OAUTH-WG] TLS 1.2

+1 Phil On 2011-08-16, at 13:04, Peter Saint-Andre wrote: > How's this? > > The authorization server MUST support Transport Layer Security > (at the time of this writing, the latest version is specified in > [RFC5246]). It MAY support additional transport-layer mechanisms > meeting its

Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)

You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter

Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21

Agreed. Phil On 2011-09-16, at 12:08, Torsten Lodderstedt wrote: > I reviewed the diffs and it looks ok. > > regards, > Torsten. > > Am 07.09.2011 17:59, schrieb Barry Leiba: >> As you've all probably seen, Eran has posted version 21 of the OAuth >> base spec, in which he believes he's addre

Re: [OAUTH-WG] AD review of -22

The issue is that the service provider will likely only accept ONE token format in practice. The security requirements of the scenario dictate choice of Mac or bearer or for that matter any other new scheme. An MTI would complicate the spec by implying a choice of tokens by the client because

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

-1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. Phil On 2012-01-03, at 15:18, Michael Thomas wrote: > Barry -- It's now been two weeks and I haven't heard anything to > the objections I raised. It is not my responsibility to come up

Re: [OAUTH-WG] Removal: Client Assertion Credentials

A strong client credential is needed in many cases. I had assumed client assertion would fulfill this need. Phil Sent from my phone. On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote: > I would like to suggest we drop the client assertion credentials (-11 section > 3.2) from the specificati

Re: [OAUTH-WG] Removal: Client Assertion Credentials

xtension mechanism for new parameters. Why is that not enough? > > > > EHL > > > > From: Phillip Hunt [mailto:phil.h...@oracle.com] > Sent: Saturday, January 15, 2011 12:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: Clien

Re: [OAUTH-WG] Removal: Client Assertion Credentials

Not sure I agree. Yes shared secret But one may be long lived (permanent) while the other may be good for minutes. If a server has both what then? I suppose we could detect type in client_secret or do it by policy associated with a client_id. Is that what is intended in the spec? As you say "

Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

The client does need to know how to authenticate. But given that it already has to know a lot about the service, you would think acceptable authentication types are well known to the client. What is the problem with the client authenticating like any normal web service client? (IE outside of o

Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

My understanding is you can still do it. It is covered by the new other auth mechanism paragraph. The real question is do we need it for interop purposes or not? We had other methods that didn't fit draft 11 either. So do u spec them all or just one mandatory to implement? Phil Sent from my

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

-1 I don't agree fully here. Phil Sent from my phone. On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote: > Yes, any token issued via OAuth by an authorization server is an OAuth token > by definition. Which makes ‘token_type=oauth2’ an silly and confusing > statement, given that any token i

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

; > phil.h...@oracle.com > > > > > > > > > On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote: > > > > > What don’t you agree with? > > > > EHL > > > > From: Phillip Hunt [mailto:phil.h...@oracle.com] > Sent:

Re: [OAUTH-WG] Client Assertion Credentials (again)

You can put in client_assertion but also leave the 'other' credential option there as well Phil Sent from my phone. On 2011-02-18, at 10:17, Hannes Tschofenig wrote: > Hi all, > > I asked for feedback regarding the removal of the client assertion > credentials earlier this month, see >

[OAUTH-WG] Lightweight web services

Thoughts on what makes up "lightweight web services" of which OAuth2 plays a key role. http://independentidentity.blogspot.com/2011/03/lightweight-web-services.html Comments welcomed. Phil Sent from my phone. ___ OAuth mailing list OAuth@ietf.org

Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

Extensibility for the new option would be defined within each spec. It doesn't seem right to put registry in bearer spec. What if one is defining a non-bearer spec? Phil Sent from my phone. On 2011-03-11, at 15:41, Mike Jones wrote: > That would be yet a different option. With (C), the ini

Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline Friday, March 18

I have not seen any detailed agenda for IETF 80. If there will be votes that override email votes all participant should so be informed. Phil Sent from my phone. On 2011-03-11, at 17:46, Anthony Nadalin wrote: >> Why the early cut-off date? As this is in advance of IETF 80, changes will >>

Re: [OAUTH-WG] Flowchart for legs of OAuth

I agree with what you are saying. We were having trouble understanding legs too, so I came up with the diagram. The diagram does show the parties aspect. But I remain uncomfortable about the terminology. Phil Sent from my phone. On 2011-03-18, at 15:55, David Primmer wrote: > Hi Phil, > >

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Why can't TLS be a must except when the token cannot be exposed. Eg because the redirect is local? Phil Sent from my phone. On 2011-03-29, at 22:48, Eran Hammer-Lahav wrote: > Francisco – thanks for being persistent. > > > > Sounds like the same problem exists in OAuth 1.0. Basically, t

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Sorry. I forgot to add it becomes a race if and only if the TS is smart enough to invalidate code after first use. Phil Sent from my phone. On 2011-04-01, at 18:07, Skylar Woodward wrote: > I'm going to summarize (hopefully faithfully) the attacks referenced here, > with the hope of attemp

Re: [OAUTH-WG] Authorization code security issue (reframed)

By not feasible, what is the technical use case/issue? Phil Sent from my phone. On 2011-04-01, at 21:52, Skylar Woodward wrote: > Am I the only one still supporting SHOULD on this case? If someone else > supports this language, please speak up. Otherwise, it seems the group SHOULD > move f

Re: [OAUTH-WG] Authorization code security issue (reframed)

For the record, I can except SHOULD. But my very strong feeling is this leads to much more lengthy and complicated language. I believe we have already crossed the line where it is no longer easy for deployers to figure out if deployments are secure. It is now a spec challenging to even subject

Re: [OAUTH-WG] Authorization code security issue (reframed)

It doesn't require client side ssl. Phil Sent from my phone. On 2011-04-04, at 11:47, Skylar Woodward wrote: > How does the client app transmit the nonce (random number) to the web browser > for redirect to the provider? If the client app does not support HTTPS, it > can't set up a secure

Re: [OAUTH-WG] Authorization code security issue (reframed)

ar Woodward wrote: >>>> >>>>> But mobile clients aren't vulnerable to this type of attack because all >>>>> of their code is contained on the device and they make all outgoing >>>>> requests to the provider via SSL. There are no redire

Re: [OAUTH-WG] Flowchart for legs of OAuth

Yes agreed. The way I read it any flow can omit client credential if they have another means to identify it. Phil Sent from my phone. On 2011-04-05, at 6:24, Justin Richer wrote: > Phil, > > It's completely within the normative language of the spec to do things > this way right now -- the

Re: [OAUTH-WG] Flowchart for legs of OAuth

Will take a look. Phil Sent from my phone. On 2011-04-11, at 8:19, Justin Richer wrote: > While this isn't the original use case I had in mind, this could be > covered by something in the OAuth2 Instance extension: > > http://tools.ietf.org/html/draft-richer-oauth-instance-00 > > -- Justin

[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

+1. I agree this is ready. PhilOn May 17, 2024, at 1:35 PM, Giuseppe De Marco wrote:+1 for publicationIl giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef ha scritto:All,This is a second WG Last Call for the OAuth 2.0 Protected Resource Metadata document (the prev

[OAUTH-WG] Re: OAuth 2.0 Protected Resource Metadata - IPR Disclosure

I am not aware of any IPR associated with this specification. Phil phil.h...@independentid.com > On Jul 10, 2024, at 9:06 AM, Rifaat Shekh-Yusef > wrote: > > Mike, Phil, Aaron, > > As part of the shepherd write-up, all authors of the OAuth 2.0 Protected > Resource Metadata draft must c