Re: [OAUTH-WG] Meeting Minutes

>> John Bradley sang a few notes from the Sound of Music to end the meeting. Were the hills alive? :) -gil -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, April 7, 2016 3:14 AM To: oauth@ietf.org Subject: [OAUTH-WG] Meeting Mi

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

While this work addresses a gap in the existing OAuth specification set, I am very concerned that this incremental extension will lead to even more confusion around the areas of “scope”, “audience” and “resource server”. I think we should try to solve this problem via a framework that provides

Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server

+1, this seems a better fit for openid. — Justin > On Apr 6, 2016, at 9:05 AM, Brian Campbell wrote: > > OpenID ... ? > > On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin > wrote: > Good question, since SCIM does not really provide an authorization model and >

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

I support adoption of this document as a starting point for working group work. — Justin > On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig > wrote: > > Hi all, > > this is the call for adoption of 'Resource Indicators for OAuth 2.0', see > http://datatracker.ietf.org/doc/draft-campbell-oauth-

Re: [OAUTH-WG] OAuth 2.1

My personal interest is to get a chance to simplify the document and add non-normative text to clarify many of the areas that have caused confusion. I’m clearly biased, but I think my original draft was much easier to read https://tools.ietf.org/html/draft-hardt-oauth-01 It could be 2.1 or 2.0.

Re: [OAUTH-WG] OAuth 2.1

Fair points. I also think this is an area where good online documentation, and books like *OAuth 2 in Action* can help, and possibly help a lot sooner. On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis wrote: > +1 > > I will not comment on the timeline for this, but I will passionately > endorse the ne

Re: [OAUTH-WG] OAuth 2.1

+1 I will not comment on the timeline for this, but I will passionately endorse the need for an OAuth 2.1 spec. Speaking as somebody who now has spent years advocating for, and building out public safety / first responder architectures built on an OAuth 2.0 architecture, I can say 2 things with c

Re: [OAUTH-WG] OAuth 2.1

And what about code injection and open redirectors? I think we already have a lot of deployment experience that should be used to evolve the spec. Sent by MailWise – See your emails as clean, short chats. Originalnachricht Betreff: Re: [OAUTH-WG] OAuth 2.1 Von: "Phil Hunt (IDM)

Re: [OAUTH-WG] OAuth 2.1

I think there are already years of implementation and experience since 2.0 If we wait until all the outstanding issues and new features have had implementations and experience, we will never do a 2.1 as there continues to be new things. I would suggest a 2.1 be a clean, simple document of the c

Re: [OAUTH-WG] OAuth 2.1

I believe all we need is a new draft that deals with the new "dynamic/mix-up" cases as these were not considered in the original spec process. The updated by method works best for this. It also consolidates a lot of piecemeal specs into one consistent spec. Phil > On Apr 7, 2016, at 15:25, M

Re: [OAUTH-WG] OAuth 2.1

Yes - an intentionally conservative, implementation- and experience-driven path. Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it until we've completed steps 1-5 below - *including* the "iterate" step, as necessary. If we get this wrong, we'll fragment OAuth, which is

Re: [OAUTH-WG] OAuth 2.1

Hi Mike, in my opinion, you described a possible path towards 2.1. Would you agree? best regards, Torsten. > Am 07.04.2016 um 13:38 schrieb Mike Jones : > > I am strongly against creating a 2.1 spec until we have at least a year of > deployment experience with the contents we're adding to 2.0,

Re: [OAUTH-WG] OAuth 2.1

Hi Tony, I'm not saying we need to define scopes or scope values. These are certainly application/API specific. Here are the issues I see: - Namespaces: there is no guidance on how to prevent clashes among scopes for different applications. Say we had used the scope value "email" for our email

Re: [OAUTH-WG] dinner Thursday night

I thought that the meeting yesterday afternoon replaced the dinner tonight. I don't have any diner info for after bits and bites. On Apr 7, 2016 1:04 PM, "Hardt, Dick" wrote: > Confirming we are still gathering for dinner tonight (Thursday) and > wondering when / where we will meet. > > > > — Di

Re: [OAUTH-WG] OAuth 2.1

The primary critique of OAuth 2.0 right now is that simply reading and implementing the spec does not guarantee interoperable implementations. If there is going to be a new OAuth 2.1 version, then it only makes sense to go through that effort if it will actually lead to interoperable implementation

Re: [OAUTH-WG] OAuth 2.1

I am strongly against creating a 2.1 spec until we have at least a year of deployment experience with the contents we're adding to 2.0, so as not to fragment the OAuth marketplace. I think we should: 1. Continue working on new security mitigations in new drafts (such as mix-up-mitigation, etc.

Re: [OAUTH-WG] OAuth 2.1

+1 on a 2.1 version -1 on defining scopes more precisely in 2.1 Sent from my iPhone > On 7 apr. 2016, at 14:46, Anthony Nadalin wrote: > > I don't belive that scopes should be defined more precisely as this > opaqueness was a design feature, I'm not seeing the reason why scopes need to > be

[OAUTH-WG] dinner Thursday night

Confirming we are still gathering for dinner tonight (Thursday) and wondering when / where we will meet. — Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1

I don't belive that scopes should be defined more precisely as this opaqueness was a design feature, I'm not seeing the reason why scopes need to be defined, as these are application specific. -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt

Re: [OAUTH-WG] OAuth 2.1

Hi all, as I already said in the meeting: I would very much prefer to have an extension/update of RFC 6819 covering all "new" threats, including: - mix up - code injection aka copy and paste - open redirector at AS and client - potential other threats in the context of "dynamic" OAuth I also ass

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

Congratulations! And what an RFC number ;-) > Am 06.04.2016 um 23:14 schrieb Mike Jones : > > The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) > specification is now RFC 7800 – an IETF standard. The abstract describes the > specification as: > > This specification describes ho

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

Surprisingly ;-), I kind of agree with Tony. We need to hash out the requirements more fully. Nat 2016-04-06 17:16 GMT-03:00 Anthony Nadalin : > I don’t see anything in the document that allows multiple resource servers > where the token can be used. Token Exchange allows delegation and > imper

Re: [OAUTH-WG] [scim] Simple Federation Deployment

Count me in ! > 7 apr. 2016 kl. 01:17 skrev Nov Matake : > > I'm interested in too. > > nov > > On Apr 7, 2016, at 07:14, Mike Jones wrote: > >> For the record, I’m interested. >> >> From: scim [mailto:scim-boun...@ietf.org] On Behalf Of Hardt, Dick >> Sent: Tuesday, April 5, 2016 7:26 PM >