Wasn't there some concensus that URIs would be good for scope? They
have in-built namespacing ...
Lukas
2010/6/23 Dick Hardt dick.ha...@gmail.com:
On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
scope
OPTIONAL. The scope of the access request expressed as
The question is whether one would ever want to have a standardized semantic for
the scope parameter.
If the answer to that question is no then it does not matter what the format
is. It can well be a list of space-delimited strings (as it is currently
defined).
An evironment specific
I recall there being consensus on the space delimiter to make it so that
URIs could be used easily as scope parameters. I know that I,
personally, would rather have keywords in our implementation than URIs,
so I'm very much in favor of keeping it unspecified.
-- justin
On Thu, 2010-06-24 at
When the API is standardized, it makes sense for the scope parameter to be
standardized. If the API is unique to the PR, then the scope will also be
unique. There may be concepts that are similar across unique APIs, but there
will be nuances that are important to be aware of.
To answer your
I'm in favor of having a spaces separated list of tokens. The only case I can
think of where the client needs to handle the scope as anything other than
opaque is when it is accessing multiple services. To reduce the numebr of
login events the client will have to poll all the endpoints it
On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard lshep...@facebook.com wrote:
One more question - is the title technique used in production? I think
you'd mentioned that it was ... if so, can you point me to the docs where
it's currently used?
Google has several Windows desktop apps that use
Hey Colin
You're right; this can be an interesting issue. It's very tied up in identity -
if you are talking about connecting accounts (like you would with Facebook)
then there's a layer missing from OAuth that provides the identity on top of
it. At the moment, there are a few proposals (for
