Defining an Extension Mechanism for both request and response would generally be useful.
Some basic design principles:
- No name space through type URI: fixed registered string for extensions.
e.g., for Open Graph, perhaps use og:variable_names OR og_variable names
where either “og:” or “og_” is the type prefix. (I kind of prefer “:” over “_” as
a separator since in CGI “-” and “_” will be identical, and in PHP GPC parameters
“.” and “_” are identical. Also, we are using “_” in the variable names already. ) - No cross interactions with other extensions
I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8.
Following is the strawman.
7. Extension Mechanism
Additional parameters MAY be defined for any request and responses.
The parameter names MUST start with a parameter prefix separated by a colon “:”.
For example:
pape:max_auth_age
Each extension MUST define its own error messages and MUST return them through
the prefixed “error” parameter.
For example:
“pape:error”:”Invalid max_auth_age format.”
Simple, is it not?
For this to work out, there has to be a register of the prefix so that it will be unique. Where should the registry be is a good question.
One approach is to create a separate spec that lists all the OAuth extension prefixes.