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