Our implementers of draft 10 have raised the following issues with draft 11.
Please address them before publishing a draft 12. I'll send editorial
feedback in a separate message.
6.2 etc.: Specification MUST permit parameter extensibility
There will be uses of OAuth2 where additional parameters need to be passed in
the messages. While some messages implicitly permit extensibility through
language like 4.1's "the client constructs the request URI by adding the
following parameters to the end-user authorization endpoint URI query
component" others do not. In particular, the BNF for the WWW-Authenticate
Response in 6.2 appears to permit only a fixed set of parameters (scope, error,
error-desc, error-uri, token). This must be addressed.
Please add language to 6.2 that explicitly allows for other arguments to be
added to the response and mandates that they be ignored if not recognized.
Also, define an IANA registration process for registering new parameter values
for all messages.
In particular, even if the following request to add an optional "resource"
parameter is not adopted, it must be possible to add one to all relevant
messages so that a "resource" parameter can be added as a legal extension.
4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1: "Scope" parameter should be paired
with complimentary "resource" parameter
It is desirable to be able to have a single service protecting multiple
resources. To achieve that, there needs to be a parameter specifying what the
desired resource being accessed is. This is different than scope. At least as
we're using it, "scope" would be a space-separated list of kinds of access
requested. For instance you might be requesting read access to someone's
calendar free/busy times and the right to post new calendar requests. Those
would be scope statements and would use URIs specifying those rights.
Therefore, we request that an additional optional "resource" parameter be added
to the specification in the same places that "scope" appears. "Resource" would
be the URI (probably a URL) of the resource being protected by the service.
5.1.3 etc.: The name client_credentials is confusing
The name client_credentials does not refer to the same concept as the uses of
the term "Client Credentials" in 1.4.3, 3, 5.1.3, and other locations in the
document. It would be far better to rename this parameter "none" or
"implicit", to indicate that no explicit credentials are being passed in the
protocol. It might also clarify this concept if you added an example.
6.2: Token_type needed for WWW-Authenticate Response
An optional token_type parameter should be added to the WWW-Authenticate
Response. This, paired with adding this parameter to the authenticated token
requests in the bearer token spec, will complete the ability to communicate
token type information for all legs of the protocol.
TBDs
And of course, we're very interested in seeing the write-ups for adding token
types in 6.1 and new credential types in 7.1
Thanks,
-- Mike
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
