Re: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling

[Brian Campbell]

The error should be invalid_grant as it is the grant (the resource
owner's username and password) that is invalid.


On Tue, Sep 13, 2011 at 10:07 AM, Colm Divilly  wrote:
> Apologies if this has been covered before, a cursory search of the archives
> and issue tracker didn't turn up anything.
>
> What is the expected error response when performing a Resource Owner
> Password Credentials flow, if the resource owner provides incorrect
> credentials?
>
> From reading the spec it looks like the expectation is that a response like
> the following should be generated:
>
>     HTTP/1.1 400 Bad Request
>     Content-Type: application/json;charset=UTF-8
>     Cache-Control: no-store
>     Pragma: no-cache
>
>     {
>       "error":"invalid_request"
>     }
>
> Which is not terribly helpful for a user-agent trying to determine that it
> is the user supplied credentials at fault (and therefore be able to
> re-prompt the user for credentials). Perhaps something like the following
> would be more useful:
>
>     HTTP/1.1 400 Bad Request
>     Content-Type: application/json;charset=UTF-8
>     Cache-Control: no-store
>     Pragma: no-cache
>
>     {
>       "error":"invalid_resource_owner_credentials"
>     }
>
> A bit verbose perhaps, any alternative suggestions?
>
> Regards,
> Colm Divilly
> ___
> 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-WG] Extensions example update (was Draft -21 next steps)

[Brian Campbell]

Although this isn't related to changes made since -20, it should
probably still be done (unless it's something for the final RFC
editors?) and shouldn't be much of a change.

The example in section 4.5 [1] uses the "old" grant type URI for the
SAML grant type (http://oauth.net/grant_type/saml/2.0/bearer) and it
should probably be updated to use the "new" and hopefully final and
stable one (urn:ietf:params:oauth:grant-type:saml2-bearer).

Here's the example from the latest SAML draft [2]:

   POST /token.oauth2 HTTP/1.1
   Host: authz.example.net
   Content-Type: application/x-www-form-urlencoded

   grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
   bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
   [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-


Also the source xml, if that's useful:


  



Thanks,
Brian

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.5
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08#section-4



On Sun, Sep 4, 2011 at 5:49 PM, Eran Hammer-Lahav  wrote:
> I’d like to ask the chairs to declare a 2 weeks review period limited to
> changes made since -20 after which we will either declare -21 as the final
> WG draft or publish a quick -22 with all changes agreed prior on the list
> and no additional WG review period. Of course, the chairs can change all
> these rules as they see fit.
>
>
>
> EHL
>
>
>
>
>
> ___
> 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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Eran Hammer-Lahav]

Just a general note: you don't need every spec to become a working group item. 
If you get an area director to sponsor your draft, you can push it through 
sooner as an individual submission. Sometimes you don't even need sponsorship.

I'm not saying this out of any objection to the WG taking on this work, just 
that I don't see a reason to wait. If you feel this simple document is ready 
and has consensus, you should find a sponsor and move to IETF LC.

EHL


From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Marius Scurtescu
Sent: Monday, September 19, 2011 11:48 AM
To: Chuck Mortimore
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-lodderstedt-oauth-revocation-03.txt

+1
On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore 
mailto:cmortim...@salesforce.com>> wrote:
If it's not already implicit by our implementation, I'm voicing our support for 
this becoming a working group item.

- cmort

On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" 
mailto:tors...@lodderstedt.net>> wrote:
Hi all,

I just published a new revision of the token revocation draft. We added JSONP 
support (thanks to Marius) and aligned the text with draft 21 of the core spec.

We would like to bring this draft forward as working group item (once the WG is 
ready). We think its relevance is illustrated by the fact that this draft (or 
its predecessor) has already been implemented by Google, Salesforce, and 
Deutsche Telekom.

regards,
Torsten.

 Original-Nachricht 
Betreff:

New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

Datum:

Fri, 16 Sep 2011 12:20:14 -0700

Von:

internet-dra...@ietf.org

An:

tors...@lodderstedt.net

CC:

sdro...@gmx.de, 
tors...@lodderstedt.net, 
mscurte...@google.com



A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been 
successfully submitted by Torsten Lodderstedt and posted to the IETF repository.



Filename:draft-lodderstedt-oauth-revocation

Revision:03

Title:   Token Revocation

Creation date:   2011-09-16

WG ID:   Individual Submission

Number of pages: 6



Abstract:

   This draft proposes an additional endpoint for OAuth authorization

   servers for revoking tokens.









The IETF Secretariat
___
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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Marius Scurtescu]

+1


On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore
wrote:

> If it's not already implicit by our implementation, I'm voicing our support
> for this becoming a working group item.
>
> - cmort
>
> On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" <
> tors...@lodderstedt.net> wrote:
>
> Hi all,
>
> I just published a new revision of the token revocation draft. We added
> JSONP support (thanks to Marius) and aligned the text with draft 21 of the
> core spec.
>
> We would like to bring this draft forward as working group item (once the
> WG is ready). We think its relevance is illustrated by the fact that this
> draft (or its predecessor) has already been implemented by Google,
> Salesforce, and Deutsche Telekom.
>
> regards,
> Torsten.
>
>  Original-Nachricht   Betreff: New Version Notification
> for draft-lodderstedt-oauth-revocation-03.txt  Datum: Fri, 16 Sep 2011
> 12:20:14 -0700  Von:  internet-dra...@ietf.org  An:
>  tors...@lodderstedt.net  CC:  
> sdro...@gmx.de, tors...@lodderstedt.net,
> mscurte...@google.com
>
> A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been 
> successfully submitted by Torsten Lodderstedt and posted to the IETF 
> repository.
>
> Filename:  draft-lodderstedt-oauth-revocation
> Revision:  03
> Title: Token Revocation
> Creation date: 2011-09-16
> WG ID: Individual Submission
> Number of pages: 6
>
> Abstract:
>This draft proposes an additional endpoint for OAuth authorization
>servers for revoking tokens.
>
>
>
>
> The IETF Secretariat
>
> ___
> 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-WG] OAuth 2.0 v21 Nits and Typos

[Anganes, Amanda L]

Lots of minor grammar and wording catches here. I apologize if any of these 
were already brought up and addressed.

1.2.3, second paragraph: "When issuing an implicit grant, the authorization 
server does not authenticate the client and in some cases, the client identity 
can be verified..." should be "When issuing an implicit grant, the 
authorization server does not authenticate the client. In some cases, the 
client identity can be verified..."

1.5, first paragraph. Last sentence should be changed to "Issuing a refresh 
token is optional. If an authorization server issues a refresh token, it is 
included when issuing an access token."

2.1, definition of public client: last sentence ends with "via any other mean" 
which should be "via any other means".
2.1, definition of native applications: "On the other hand, dynamically issued 
credentials such as access tokens or refresh tokens, can receive an acceptable 
level of protection" should be "On the other hand, dynamically issued 
credentials such as access tokens or refresh tokens can receive an acceptable 
level of protection" (final comma is unnecessary).

3.1, second paragraph. Add a comma after "beyond the scope of this 
specification", so it reads "The means through which the client obtains the 
location of the authorization endpoint are beyond the scope of this 
specification, but the location is typically provided in the service 
documentation".

3.2.1, first sentence. Unnecessary comma between "requirements" and "MUST"; 
should read "Confidential clients, clients issued client credentials, or 
clients assigned other authentication requirements MUST authenticate..."

4.1, section (E): last sentence is missing a subject. "If valid, responds back 
with an..." should read "If valid, the authorization server responds back with 
an..."

4.1.2 and 4.1.2.1, also 4.2.2 and 4.2.2.1, state description: last sentence is 
missing a MUST. Should read "REQUIRED if the state parameter was present in the 
client authorization request. The state parameter MUST be set to the exact 
value received from the client."

4.1.3, redirect_uri description: Change "REQUIRED, if the redirect_uri 
parameter was included in the authorization request described in Section 4.1.1, 
and their values MUST be identical" to "REQUIRED, if the redirect_uri parameter 
was included in the authorization request as described in Section 4.1.1. If 
included, the two values MUST be identical".

4.1.3, final paragraph ("The authorization server MUST: ..."). Is any 
additional normative language required for lists such as this in order to 
specify that the AS must do ALL of the items in the list? Similar MUST lists 
appear elsewhere throughout the rest of the document.
Also, final bullet should be reworded; suggest "ensure that the redirect_uri 
parameter is present if the redirect_uri parameter was included in the initial 
authorization request as described in Section 4.1.1, and if included ensure 
that their values are identical".

4.2, first paragraph: clarify that implicit grants can be used only for access 
tokens by including the word "only" here: "The implicit grant type is used to 
obtain access tokens only..."

4.3.2, paragraph after term parameter descriptions: "If the client type is 
confidential or was issued client credentials" should be reworded to "If the 
client type is confidential or the client was issued client credentials".

9, bullets following second paragraph: Change this to a definition list format 
instead of a bulleted list.
9, final bullet following "when choosing between an external or embedded 
user-agent...": Last sentence starts "Embedded user-agent educate..." but 
should be "Embedded user-agents educate..."

10.2, second paragraph: last sentence is a fragment. Reword to "For example, 
the authorization server should engage the resource owner to assist in identify 
the client and its origin."

10.5, second paragraph, first sentence: extraneous comma between "authorization 
server" and "is". Should be "...verify that the resource owner who granted 
authorization at the authorization server is the same resource owner..."

10.6, last paragraph, first sentence: extraneous comma between "authorization 
code" and "is the same". Should be "... the authorization server MUST ensure 
that the redirection URI used to obtain the authorization code is the same as 
the redirection URI provided ..."
Last sentence should be reworded; suggest "The authorization server MUST 
require public clients and SHOULD require confidential clients to register 
their redirection URIs. If a redirection URI is provided in the authorization 
request, the authorization server MUST validate the URI received against the 
registered value."

10.14, first sentence. Reads awkwardly and should be reworded; suggest "A code 
injection attack occurs when an unsanitized input or otherwise external 
variable is used to modify application logic."

11.1, 11.2, 11.3, 11.4: second to last paragraph is missing "

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Justin Richer]

I also want to voice support for this. We've implemented an earlier
version of this on a few of our projects as well.

 -- Justin

On Fri, 2011-09-16 at 16:06 -0400, Chuck Mortimore wrote:
> If it's not already implicit by our implementation, I'm voicing our
> support for this becoming a working group item.   
> 
> - cmort
> 
> On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt"
>  wrote:
> 
> 
> 
> > Hi all,
> > 
> > I just published a new revision of the token revocation draft. We
> > added JSONP support (thanks to Marius) and aligned the text with
> > draft 21 of the core spec.
> > 
> > We would like to bring this draft forward as working group item
> > (once the WG is ready). We think its relevance is illustrated by the
> > fact that this draft (or its predecessor) has already been
> > implemented by Google, Salesforce, and Deutsche Telekom.
> > 
> > regards,
> > Torsten.
> > 
> >  Original-Nachricht  
> >  Betreff: 
> > New Version Notification for
> > draft-lodderstedt-oauth-revocation-03.txt
> >Datum: 
> > Fri, 16 Sep 2011 12:20:14 -0700
> >  Von: 
> > internet-dra...@ietf.org
> >   An: 
> > tors...@lodderstedt.net
> >   CC: 
> > sdro...@gmx.de,
> > tors...@lodderstedt.net,
> > mscurte...@google.com
> > 
> > 
> > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been 
> > successfully submitted by Torsten Lodderstedt and posted to the IETF 
> > repository.
> > 
> > Filename:draft-lodderstedt-oauth-revocation
> > Revision:03
> > Title:   Token Revocation
> > Creation date:   2011-09-16
> > WG ID:   Individual Submission
> > Number of pages: 6
> > 
> > Abstract:
> >This draft proposes an additional endpoint for OAuth authorization
> >servers for revoking tokens.
> > 
> > 
> >   
> > 
> > 
> > The IETF Secretariat
> > ___
> > 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