Just as a matter of clarification about the downscope language in the
spec:
The downscoping capability here is intended mostly for getting
special-use tokens, for things like redelegation to other apps. So say I
grant access to AppA with scope "read write", and AppA gets a refresh
and access token
As Eran pointed out, the way you've formatted your scope request,
you've only specified one scope and I'd guess to keep things simple
and consistent can either be approved or denied. I don't have a spec
reference about what happens when the user doesn't approve but I
assume the response is sent to
Nat Sakimura wrote:
I think such things are better dealt with extensions.
Sure. But first we need to define that which we will later extend.
I do not like to overload "scope".
Neither do I, as long as "overloading" means varying the original
semantics. But, again, at the moment we h
I think such things are better dealt with extensions.
I do not like to overload "scope".
=nat
On Sat, Nov 27, 2010 at 5:26 AM, Igor Faynberg
wrote:
> In the context of Martin's question (which concerns end-users understanding
> and resulting actions), I interpret the citation as follows: The en
In the context of Martin's question (which concerns end-users
understanding and resulting actions), I interpret the citation as
follows: The end-user has no control over the value of the "scope"
parameter, and, given that "it is defined by the authorization server,"
the end-user is not expected
-10 4.2:
scope
OPTIONAL. The scope of the access token as a list of space-
delimited strings. The value of the "scope" parameter is
defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter,
