Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

If the malicious client is registering it’s own redirect URI then option A won’t help. On the other hand the Good AS should identify the malicious client to the user. I think this is a separate problem of client impersonation being used for Phishing. This is really a case of bad guy registers

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Hi Hannes, I'm glad to hear that you're interest to work on this. The approach in the Trier report was really enlightening to me. I'm still digesting it. OAuth 2 was created with the promise to be developer friendly and extensible, but compared with some other security protocols, doesn't extend s

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I know that at least in Azure, developers can dynamically add resources for use by the client using the developer portal at any time. Therefore, at client configuration time, which is when AS discovery is used, there is not an authoritative list of resources available. I believe that Brian sai

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

To clarify…. I am not suggesting that we need a resource discovery mechanism. What I am suggesting is much simpler. I propose that the authorization confirm that the endpoint that the client has discovered is a resource that the AS can issue tokens for (in other words is a valid audience for th

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Thanks for taking the time to propose specific text, Phil. That’s really helpful. I’ll plan to incorporate a version of this in the draft addressing WGLC comments. I agree with Vladimir’s observation that it’s difficult to come up with a general-purpose resource discovery mechanism. That in

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On 27/02/16 20:10, Phil Hunt wrote: > The name change seems appropriate given that the WG members have decided not > to address the issue of resource discovery as part of this specification. > > If the consensus is to limit the scope of the specification, then I suggest > the following security

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Hi Brian, On 27/02/16 00:27, Brian Campbell wrote: > My preference is for Option A. > > The mix-up attack, in all it's variations, relies on there being no means > in OAuth for the AS to identify itself to the client when it returns the > user's browser to the client's redirect_uri. 'OAuth 2.0 Mix

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The name change seems appropriate given that the WG members have decided not to address the issue of resource discovery as part of this specification. If the consensus is to limit the scope of the specification, then I suggest the following security considerations text. Resource Discovery Secu

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

It’s clear that people want us to move to the name “OAuth 2.0 Authorization Server Discovery”. The editors will plan to make that change in the draft addressing Working Group Last Call comments. Thanks all,

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

+1 Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Xing #E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Brian Campbell [mailto:bcampb...@pingidentity.co

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery” //Samuel On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones wrote: > Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept > your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth > 2.0 Authorization Server Discover

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 Sent by MailWise – See your emails as clean, short chats. Originalnachricht Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location Von: Justin Richer An: George Fletcher Cc: "" >+1 for “OAuth 2.0 Authorization Server Discovery” > > — Justin > >> On Feb 25, 2016, at 2:20 PM,