hat type='AD'/
On 3/19/11 11:58 AM, Hannes Tschofenig wrote:
Hi all,
the WGLC for the OAuth base specification has been completed and the
authors think that this document is ready for a WGLC as well.
Hence, let us start the last call for comments on
hat type='AD'/
On 3/2/11 1:31 AM, Hannes Tschofenig wrote:
This is a Last Call for comments on
http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt
Please have your comments in no later than March 25 (extended deadline
because of the ongoing OAuth base specification WGLC).
Do
FYI. I have posted a new version of the flows on my blog showing the new
terminology as discussed here. Feedback appreciated.
http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html
Phil
phil.h...@oracle.com
On 2011-03-19, at 11:37 AM, Anil Saldhana wrote:
I agree. 2 party
Hi Phil,
looks even better now :-)
As already pointed out
(http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html),
Have client credentials? No does not automatically imply usage of
implicit grant. The client could also use the authorization code (for
various reasons).
regards,
Here are my comments on this draft:
I repeat my proposal to name the URI parameter for passing the token
bearer_token instead of oauth_token. The same applies to the
respective body parameter. This is more inline with the I-D's terminology.
section 2.4
If the protected resource request does
hat type='AD'/
On 3/2/11 12:32 AM, Hannes Tschofenig wrote:
This is a Last Call for comments on
http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt
Please have your comments in no later than March 16.
Do remember to send a note in if you have read the document and have no
other
Thank for the review and comment, Peter, some replies and new
questions are inline below.
On Wed, Mar 23, 2011 at 11:05 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
I've completed a review of this spec, the bearer token spec, and the
base spec. This is the first WGLC message I found in my
Not ignoring points made along the way as there are points from each view
point, and not sure it's counterproductive to state the issues and what is
driving the issues on a single list. So let's move on.
I don't believe that there is anything wrong in combining into a single
registry, as this
-Original Message-
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Wednesday, March 23, 2011 3:11 PM
I don't believe that there is anything wrong in combining into a single
registry, as this has been done in other specifications.
There are very different endpoints with
