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

I "hear your pain" but I'm not sure this is a good idea.
What you describe sounds more like debugging to me.
Not something I'd put in the protocol msgs.

Hubert

On Mon, Sep 21, 2009 at 11: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
>