Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)

I have one question about the Problem Reporting extension.  The current text
says:

*user_refused*: The User (in most cases it's just user's IP) is temporarily
unacceptable to the Service Provider. For example, the Service Provider may
be rate limiting the IP based on number of requests. This error condition
applies to the Authorization process where the user interacts with Service
Provider directly. The Service Provider might return this error in the
authorization response or in the Access Token request response.

Q: Why is this (rate limiting) limited to the first two steps of the
protocol, and not the Protected Resource request?  I have many use cases
where I also need to rate limit accesses, often based on the user or their
IP, and user_refused is the only detail I coudl provide.  But the PR
extension seems to explicitly exclude this usage.  Why?

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Mon, Sep 21, 2009 at 2:50 PM, Chirag Shah <chiragshah1@gmail.com> wrote:

> > * The proposed Problem Reporting extension [1], its richness and
> complexity
>
> I was curious if we could slightly update to the proposed problem
> reporting extension.
>
> The signature_invalid section in the Problem Reporting extension[1]
> should encourage service providers to include the
> signature_base_string they used in the error response.
>
> This information is valuable because the consumer can visually
> identify why their signature is invalid by comparing their
> signature_base string against the service provider's. If the service
> provider does not provide this information, the consumer is often
> guessing why their signature is invalid.
>
> [1] - http://wiki.oauth.net/ProblemReporting
>
> On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > http://tools.ietf.org/html/draft-ietf-oauth-authentication
> > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation
> >
> > I plan to publish new revisions of the above drafts to include:
> >
> > * Error codes and optional debug information
> > * Cleanup of the authentication extensibility model
> > * Change the version / protocol extensibility model
> >
> > In addition to general feedback about the drafts, I am looking for
> specific feedback on the following items which I plan to address in the next
> drafts:
> >
> > * Drop core support for the RSA-SHA1 method
> > * Replace HMAC-SHA1 with HMAC-SHA256
> > * Define the authentication parameters as method-specific (for example,
> drop nonce and timestamp from PLAINTEXT)
> > * The proposed Problem Reporting extension [1], its richness and
> complexity
> > * Making the HMAC signature method required for all server
> implementations
> > * Changing the delegation flow to require HTTP POST instead of
> recommending it
> > * Mandating server support for all three parameter transmission methods
> > * Adding a token revocation endpoint
> > * Adding the ability for servers to declare their configuration (methods,
> etc.) in the WWW-Authenticate header response
> > * The value of the client credentials (Consumer Key) and feedback from
> actual implementation experience
> >
> > In order for your feedback to be included or considered for the next
> revisions it must be received by 10/2 on the oauth@ietf.org list.
> >
> > EHL
> >
> > [1] http://wiki.oauth.net/ProblemReporting
> >
> > _______________________________________________
> > 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
>