> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Mike Jones
> Sent: Tuesday, March 15, 2011 7:52 AM
> 2.1.1: "If no valid redirection URI is available, the authorization server
> SHOULD" - I don't understand why this is a SHOULD and not a MUST
Because we cannot mandate how the authorization server interacts with the
resource owner. Some server may choose ignore the error and send the user to
some landing page.
> 3: Restore Client Assertion Credentials
>
> Restore the Client Assertion Credentials feature that was present in draft 11,
> section 3.2.
Previously rejected due to no working group consensus.
> 4.1.1: Scope string matching rules are ambiguous
>
> In the "scope" definition, add "The space-delimited strings are case
> insensitive."
Good call.
> 4.1, 4.2, 4.3.2, 4.4.2, 5.1, 6: "Scope" parameter should be paired with
> complimentary "resource" parameter
Previously rejected due to no working group consensus.
> 4.2.2: Add optional "expires_at" parameter
Previously rejected due to no working group consensus.
> 4.4.2 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.4 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.
We had a long discussion about this and the consensus was to name it
'client_credentials'. Both 'none' and 'implicit' were rejected.
> 7: Restore WWW-Authenticate Response Header Field
>
> Restore the WWW-Authenticate Response Header Field that was present in
> draft 11, section 6.2.
Previously rejected due to no working group consensus.
> 10: Add OAuth Errors Registry
>
> Add the OAuth Errors Registry from the bearer token specification, draft 03,
> section 4.3, to the IANA Considerations.
Previously rejected due to no working group consensus. An alternative proposal
coming.
> 10.2: Add parameter locations to OAuth Parameters Registry
>
> Add the "resource request" and "resource response" parameter locations, as
> defined in the bearer token specification, draft 03, section 4.2, to the OAuth
> Parameters Registry.
Previously rejected due to no working group consensus.
> 2.1.1: "resource owner's user-agent" this may not be possible if the resource
> owner is a device or if the resource owner does not have a user agent
User-agent is an generic HTTP term.
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
> 4.1.1: "parameters are present and valid" - there are no processing
> requirements section to determine what "valid" means; suggest that a
> processing section be added to understand what "valid" means otherwise
> remove the references to "valid"
It is pretty obvious that valid == as defined (case sensitive, value format,
not repeating, etc.).
> 4.2.1: "Due to lack of client authentication" - not sure what this is trying
> to
> get at here as this is just a client id; nothing about its usage is called
> out, thus
> this should go in the Security Considerations section, not here in the main
> text
This has been a big PR issue for part versions and needs to be called out
explicitly right there. Changed to:
"The client identifier alone MUST NOT be relied upon for client
identification as it provides no means for authentication."
> 4.5: Remove "I-D.ietf-oauth-saml2-bearer" until this becomes a standard
> 11.2: remove references to "I-D.hammer-oauth-v2-mac-token-02", "I-D.ietf-
> oauth-v2-bearer-02", "I-D.ietf-oauth-saml2-bearer-03" until these become
> standards
The RFC editor takes care of that.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
