It's time to decide how we want to treat access token scope in the specification. Note that this discussion is limited to *requesting* an access token with a specific scope and does not include how to decide when a token should be reused against an unfamiliar server (i.e. resource server advertising which scope it requires).
Below is the list of options with enough group interest. I didn't my best to represent each option without bias but please feel free to add more details with your votes. If you feel strongly about other alternatives, please list them in your reply. Please reply by 5/5. EHL --- 1. Parameter Name Only Define a token request parameter 'scope' leaving the value structure undefined. This will allow libraries to define a built-in parameter to pass scope up and down the stack. Each provider will need to document their use of the parameter, including delimiter and encoding. Pros: - This does not require specifying a format that may conflict with existing or desired vendor-specific needs. - There isn't enough deployment experience to go further than that. - It makes using a library easier for client developers Cons: - Adding an undefined parameter can hurt interoperability in the long run because as soon as it is deployed it will become impossible to standardize this value in the future. - Libraries are likely to implement the most popular form of scope encoding which will conflict with other vendors. - Specifying a generally useful format isn't that hard, but is very useful. - Libraries will need to pass arbitrary parameters anyway to accommodate other vendor-specific extensions. 2. No Scope Parameter The protocol will remain mute on the subject, allowing vendors to introduce their own scope parameter either as an extension or as an opaque part of the authorization and token endpoints (as proposed by James Manger). Pros: - Simplicity - the protocol doesn't define (partially or fully) parameters that are not required in every implementation. - Flexibility - since there is no consensus on the subject, this allows vendors to define their own parameters with more suitable names (e.g. 'resources', 'permission', 'duration', etc.). Cons: - Every implementation is likely to add such a parameter anyway. - The pattern described by James isn't obvious and developers are likely to reinvent a scope parameter instead. - Goes against common expectation of scope support in the core protocol. 3. Space-Delimited Scope Parameter Value Define a 'scope' parameter with value of space-delimited strings (which can include any character that is not a space - the entire parameter value is encoded per the transport rules regardless). Space allows using URIs or simple strings as values. Pros: - A separator-delimited list of values is the common format for scope parameters in existing implementations and represents actual deployment experience. - Most vendors define a set of opaque strings used for requesting scope. This enables libraries to concatenate these in a standard way. - Enables simple extensions in the future for discovering which scope is required by each resource. Cons: - Defining a format without a discovery method for the values needs doesn't offer much more than the other options. - Doesn't go far enough to actually achieve interoperability. - Adds complexity for little value. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
