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

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 13:40:30 -0700

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 [email-masked] list.

EHL

[1] http://wiki.oauth.net/ProblemReporting

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Sep 2009 15:25:23 -0600

<hat type="chair"/>

> I plan to publish new revisions of the above drafts to include:

<snip/>

Great idea, and thanks for the push.

To help move things forward, we might want to hold a real-time meeting
in our WG chatroom:

   xmpp:[email-masked]

   http://jabber.ietf.org/logs/oauth/

I think it would be productive to do that the week of October 5, after
your October 2 deadline has passed, so that we can efficiently work
through any remaining open issues.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 14:50:47 -0700

Sounds good. Can you propose a time?

EHL

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Monday, September 21, 2009 2:25 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due
> 10/2)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> <hat type="chair"/>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkq370MACgkQNL8k5A2w/vwGLwCcDUAvKui+gMcJD955bM0k06vj
> AdgAoIsI20q3W5uUlY9cnwJTlE7jYiaw
> =9uK2
> -----END PGP SIGNATURE-----

---

From: Chirag Shah <[email-masked]>
Date: Mon, 21 Sep 2009 14:50:43 -0700

> * 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 <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 14:57:26 -0700

I misspoken. I am travelling 10/7-12.

Not sure if the list is the best way to schedule such a meeting... :-)

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, September 21, 2009 2:51 PM
> To: Peter Saint-Andre
> Cc: [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Sep 2009 15:58:49 -0600

<hat type="chair"/>

How about Wednesday, October 7, at 17:00 UTC?

That would be 10:00 on the U.S. West Coast, 13:00 on the U.S. East
Coast, 18:00 in the UK, 19:00 in most of Western Europe, etc.

---

From: Hubert Le Van Gong <[email-masked]>
Date: Mon, 21 Sep 2009 23:59:12 +0200

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Sep 2009 16:01:02 -0600

Perhaps not, but I say we stipulate a time and just get it done. Whoever
shows up, shows up.

How about:

Monday, October 5 @ 17:00 UTC?

---

From: John Panzer <[email-masked]>
Date: Mon, 21 Sep 2009 15:07:55 -0700

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
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Mon, Sep 21, 2009 at 2:50 PM, Chirag Shah <[email-masked]> wrote:

> > 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:
> >
> > * Adding the ability for servers to declare their configuration (methods,
> etc.) in the WWW-Authenticate header response
> > In order for your feedback to be included or considered for the next
> revisions it must be received by 10/2 on the [email-masked] list.
> >
> > EHL
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 16:31:10 -0700

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

EHL

> Of Hubert Le Van Gong
> Sent: Monday, September 21, 2009 2:59 PM
> To: [email-masked]
> specific feedback on the following items which I plan to address in the
> next drafts:
> >>
> >> * Define the authentication parameters as method-specific (for
> example, drop nonce and timestamp from PLAINTEXT)
> >> * Adding the ability for servers to declare their configuration
> (methods, etc.) in the WWW-Authenticate header response

---

From: Chirag Shah <[email-masked]>
Date: Mon, 21 Sep 2009 17:05:36 -0700

Isn't the purpose of the Problem Reporting extension is to help
developers debug OAuth issues?

Currently the text "signature_invalid" isn't very meaningful to
developers debugging their applications because they want to know the
exact reason why.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 17:15:19 -0700

I think we need to clean up the problem reporting proposal and separate between codes that help debug and codes that call for an action. All the errors which cannot be handled automatically by an application should be just marked as fail. The specifics of such fail are only useful for human debugging and while valuable, should be part of exactly that - debugging capabilities.

EHL

> Of Chirag Shah
> Sent: Monday, September 21, 2009 5:06 PM
> To: Hubert Le Van Gong
> Cc: [email-masked]
> >>> In order for your feedback to be included or considered for the
> next revisions it must be received by 10/2 on the [email-masked] list.
> >>>
> >>> EHL
> >>>