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

2016-02-22 Thread Nat Sakimura
[case1] Code phishing + cut-n-paste attack [case1a] through BadAS to GoodAS redirect [case1b] through tampering the unprotected client access response [case1c] through the server log [case2] Token phishing (in case of implicit flow). [case3] Code and Client credential phishing All

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

2016-02-22 Thread Thomas Broyer
Couldn't the document only describe the metadata? I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration". The metadata described here would then either be used as-

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

2016-02-22 Thread Justin Richer
I think you can really do both parts in the document without harm. Specifying a ".well-known" location doesn't preclude you from including the same metadata elsewhere as well, such as with oauth-meta or with a service-specific discovery document (like openid-configuration). But it would be nice

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

2016-02-22 Thread John Bradley
Inline > On Feb 22, 2016, at 9:22 AM, Nat Sakimura wrote: > > [case1] Code phishing + cut-n-paste attackĀ  <> > [case1a] through BadAS to GoodAS redirect > [case1b] through tampering the unprotected client access response > [case1c] through the server log > [case2] Token phishing (in case o