On 2010-04-18, at 9:56 PM, Eran Hammer-Lahav wrote:
> The client_id parameter is not expected to have an internal structure known
> to clients.
The client developer needs to understand it.
> The likelihood of a client library treating this value as anything other than
> an opaque string is practically zero. client_id is well defined, especially
> when it comes to how clients are expected to interact with it. I have not
> seen a single implementation or requirement to put client-aware meaning into
> the client_id parameter value. It is an opaque, server-issued string.
What about the format parameter that specifies that assertion?
>
> The proposed scope parameter is expected to always have an internal structure
> and clients are expected to read some documentation explaining how to use it.
> The likelihood of a client library to implement one such structure based on
> the first service it is used for is not insignificant. And once one popular
> service use it in one way, others are likely to do the same to make their
> developers life easier. So why leave this up to the first popular service to
> decide.
This does not make sense. Services are already defining scope parameters,
libraries are adding them in.
The client library should treat the scope parameter as a string just like all
the other strings that are passed around. Given that a number of popular
services have a scope like parameter now, I don't know of a situation where a
library developer has done what you fear.
>
> Libraries are expected to pass up and down *any* parameter, regardless of its
> status as a core protocol parameter or not. A library that doesn’t is broken.
> If they do that, defining a scope parameter adds absolutely nothing. For
> example, we can add a language parameter which will be used by the client to
> request a specific UI language experience but leave the value to be server
> specific. Clearly this is useless without defining how the parameter shall be
> used. From an interop and spec perspective, how is scope different?
It is much simpler for the library to have an interface where you specify
specific values than hand in an arbitrary set of name value pairs.
>
> The current proposal is to pick an ambiguous term and add it as a parameter
> with no clear meaning, purpose, or structure. I don’t know what scope means.
> Does it include permissions? The desired access lifetime? The ability to
> share the tokens with other providers? Different HTTP methods? All the
> examples I have seen treat it as a list of resources either directly (list of
> URIs) or indirectly (list of sets or service types).
It could be any of those things. The scope of access that the client is asking
for.
>
> How about we also add a ‘redelegation’, ‘duration’, ‘permission’, ‘methods’,
> and a few more and leave them all server specific? According to the proposal
> logic, why not?
Those would all be included under scope.
Many implementors are saying they want the scope parameter. Are there
implementors / deployers that don't want it? You seem to have a strong opinion
on this point that is based on a potential interop fear you have that is
contrary to many implementors.
-- Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
