I don't support alternative response_types; I don't support dynamic redirect_uri (at the moment, it's completely static; in future we may offer the list option), and the allowed scope for a given client is set during setup -- you can't then request a scope you aren't authorized for, given your client id.
I'm not breaking the spec -- it offers all of these paths as options. You don't have to implement all of the possibilities the spec covers.
The bad thing about the spec is that some of the possible paths are indeed less secure (it even says so in the spec in places...), so the security of your OAuth2 implementation is purely up to your judgement.
The nice thing about good specs is that you benefit from the presumably-better judgement of the folks designing the spec....
I don't support alternative response_types; I don't support dynamic redirect_uri (at the moment, it's completely static; in future we may offer the list option), and the allowed scope for a given client is set during setup -- you can't then request a scope you aren't authorized for, given your client id.
I'm not breaking the spec -- it offers all of these paths as options. You don't have to implement all of the possibilities the spec covers.
The bad thing about the spec is that some of the possible paths are indeed less secure (it even says so in the spec in places...), so the security of your OAuth2 implementation is purely up to your judgement.
The nice thing about good specs is that you benefit from the presumably-better judgement of the folks designing the spec....