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

Is there any past experience with protocols adding explicit debugging support? If we make it optional, it would be very useful.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Hubert Le Van Gong
> Sent: Monday, September 21, 2009 2:59 PM
> To: oauth@ietf.org
> Subject: 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
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth