I would leave that to be AS defined -- different delimiters make sense in different environments -- it could be an expression -- just make it a string -- it will need to be URL encoded which will deal with any magic characters.
-- Diok On 2010-04-18, at 6:38 PM, David Recordon wrote: > I think we need to add a bit more definition to the scope parameter. > Maybe as simple as a comma-separated list of strings. > > > On Sun, Apr 18, 2010 at 6:12 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> 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> >> 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 >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
