The client_id parameter is not expected to have an internal structure known to clients. 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.
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. 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? 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). 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? EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Sunday, April 18, 2010 6:12 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Issue: Scope parameter The scope parameter was included in WRAP at the request of library and AS implementors to standardize a commonly included parameters. The client_id parameter seems similar to the scope parameter. The meaning of client_id is not defined in the spec and is AS specific. A client_id that a developer uses with one AS may be different at a different AS. The argument that defining the scope parameter will cause more confusion is confusing itself. Why would a developer think they can use the same scope at two different AS? The developer has to manage different client_ids, different endpoint URIs and different PRs: not to mention different APIs. Having a different scope between AS seems natural. Having a vendor defined parameter name for different AS that all mean scope seems suboptimal. A related example. Email has a subject parameter, we all have a similar idea what it means, and it can be used differently in different situations, but it was useful to create the placeholder for the optional subject of an email message. Proposal: put optional scope parameter back into all calls to obtain an access token. Put optional scope parameter into calls to refresh an access token. -- Dick On Thu, Apr 15, 2010 at 12:07 PM, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: WRAP includes a loosely defined scope parameter which allows for vendor-specific (and non-interoperable) use cases. This was requested by many working group members to be included in OAuth 2.0 with the argument that while it doesn't help interop, it makes using clients easier. The problem with a general purpose scope parameter that is completely undefined in structure is that it hurts interop more than it helps. It creates an expectation that values can be used across services, and it cannot be used without another spec defining its content and structure. Such as spec can simply define its own parameter. In addition, it is not clear what belongs in scope (list of resources, access type, duration of access, right to share data, rights to re-delegate). The rules should be that if a parameter cannot be used without another documentation, it should be defined in that other document. Proposal: Request proposals for a scope parameter definition that improve interop. Otherwise, keep the parameter out of the core spec. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
