Thanks for the feedback.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 1:59 PM
> 2.1 Client types
>
> I'm struggeling with the new terminology of "private" and "public"
> clients. In
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 2:15 PM
> "The authorization server redirects the user-agent to the
> client's redirection URI previously established with the
>
True.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 2:19 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue 17, new token endpoint Client Authentication
> section (3.2.1)
>
> just a minor
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, July 20, 2011 2:49 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Comments on -18
>
> section 1.5
>
> "(A) The client requests an access token by authentic
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer-Lahav
Draft 19 includes all the feedback received for -18:
* Closes issues 15-19
* Moved client profiles to section 2.1 from 10
* New text for 'Code Injection and Input Validation'
* A few minor editorial clarifications
There are two open issues (20, 21) which are minor editorial requests, and the
req
Sounds good Eran
On 25 July 2011 07:37, Eran Hammer-Lahav wrote:
> This seems too verbose, considering how fundamental input validation is in
> general.
>
> ** **
>
> I added the following to a new section:
>
> ** **
>
> A code injection attack occurs when an input or otherwise
On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote:
> Draft 19 includes all the feedback received for -18:
BTW, the diff is here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt
/psa
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai
On Mon, 25 Jul 2011, Peter Saint-Andre wrote:
On 7/25/11 4:06 AM, Eran Hammer-Lahav wrote:
Draft 19 includes all the feedback received for -18:
BTW, the diff is here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-19.txt
clarifying question on section 10.1 -
I'm reading this as s
You're correct about the missing comma. I'll plan on updating the draft this
week.
To your second question, the definition of quoted-string does allow for
unquoted whitespace within the quoted string.
-- Mike
-Original Message-
From: Ian McKellar [mailt
I need to revisit a question that came up about two months ago. I
thought I had a clear understanding of when client_id was and wasn't
included in access token requests but drafts 18/19 seemed to have
changed things (or my understanding of 16 was wrong).
The question is, when is client_id a requi
can some one verify and publish pdf format documents again?
All empty pages, starting from 6 or 7 page.
all the active documets.
Thanks
dhiva
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
I would avoid using the term "open" here as it has other deep-seated
meanings in the software world, particularly with regard to Open Source
and Open Standard stuff. FWIW, I think "confidential/public" or
"private/public" are serviceable.
-- Justin
On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-
Hi Eran,
section 5.2
"The authorization server MAY return an HTTP 401
(Unauthorized) status code to indicate which HTTP
authentication schemes are supported."
Given the usage of HTTP authentication schemes is the way to authenticated
client recommended by the s
A few editorial points about references:
- the draft is referencing an old draft of the bearer token spec (-04),
rather than the current version (-06),
- the draft is referencing an old draft of the SAML bearer spec (-03),
rather than the current version (-04),
- the draft is not referenci
Hi Eran,
Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 2:15 PM
"The authorization server redirects the user-agent to the
client's redir
+1
Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav:
How about, add this to 10.1:
When client authentication is not possible, the
authorization server SHOULD employ other
means to validate the client's identity. For example, by
requiring the registration of
th
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, July 25, 2011 7:24 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Comments on -18
>
> Hi Eran,
> >> section 5.2
> >>
> >> "The authorization server MAY return an HTTP 40
BTW, I'm planning on following -19 with -20 later today with text closing all
the remaining issues.
EHL
From: Eran Hammer-Lahav
Sent: Monday, July 25, 2011 1:07 AM
To: OAuth WG
Subject: Draft -19
Draft 19 includes all the feedback received for -18:
* Closes issues 15-19
* Moved client profiles
Yeah, I'm not going to waste time trying to keep these in sync for now. This
will all be done once before IETF LC and then with the RFC editor.
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Draft -19
A
The term Redirection URI describes the URI provided by the client throughout
the document. The additional parameters added later by the authorization server
are part of the redirection request but not the URI provided by the client.
EHL
> -Original Message-
> From: Lucy Lynch [mailto:ll
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Monday, July 25, 2011 7:19 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
>
> Hi Eran,
>
> Am 25.07.2011 03:28, schrieb Eran H
I'll switch to confidential/public.
EHL
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, July 25, 2011 7:41 AM
> To: Eran Hammer-Lahav
> Cc: e...@sled.com; Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] Issue 15, new client registration
>
> I
client_id is only required on the authorization endpoint, not the token
endpoint. -18 cleaned up how the document talked about client authentication in
general. So you should remove client_id from your draft and instead mention
client authentication (if appropriate).
EHL
> -Original Messag
How should HTTP Basic be used for a client not in possession of a
client secret?
On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav wrote:
> client_id is only required on the authorization endpoint, not the token
> endpoint. -18 cleaned up how the document talked about client authentication
It shouldn't. You are still allowed to reuse client_id outside the specific
password credentials use case. Just make sure the way the parameter is defined
in v2 is consistent.
EHL
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> Sent: Monday, July 25, 20
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer-Lahav
Draft -20 closes all open issues. Any additional feedback will be part of the
WGLC process.
Thanks,
EHL
From: Eran Hammer-Lahav
Sent: Monday, July 25, 2011 9:10 AM
To: 'OAuth WG'
Subject: RE: Draft -19
BTW, I'm planning on following -19 with -20 later today with text closing all
the remaining
On Mon, 25 Jul 2011, Eran Hammer-Lahav wrote:
The term Redirection URI describes the URI provided by the client
throughout the document. The additional parameters added later by the
authorization server are part of the redirection request but not the URI
provided by the client.
Thanks -
EH
ok
Am 25.07.2011 11:53, schrieb Eran Hammer-Lahav:
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, July 25, 2011 7:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Comments on -18
Hi Eran,
section 5.2
"The authorization ser
Hi Eran,
Regarding this particular section: I think the two different issues (transport
security and endpoint authenticity) should be presented separately.
Which section?
3.1.2.1.
regards,
Torsten.
EHL
___
OAuth mailing list
OAuth@ietf.org
https
I'm asking from both an implementation perspective as well as the spec
perspective.
On the spec side, draft-ietf-oauth-assertions will deal with client_id
and while it's currently required I'd guess it will become optional or
even forbidden.
On the implementation side, let me make sure I understa
Hi Eran,
OAuth 1.0 was highly criticized for failing to address client identity
in public clients. I believe OAuth 2.0 offers a much better story,
within the boundaries>of what’s possible today.
Agreed. I think we must honestly discuss the value of client
authentication/identification itself. I
People attending in person should be aware that the room we have is
not large. It claims to hold 60, which I think is a generous
estimate. I advise folks to be prompt, so as to get a seat. If we
get a good turnout, we may overflow the room.
Barry
___
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> Sent: Monday, July 25, 2011 10:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
> identification
>
> I'm asking from both an implementation p
Since these issues are covered in the security section, I think it is enough to
simply stress the importance of using TLS for the redirection endpoint and
leave the more detailed analysis for later in the document.
But if you want to propose new text, I'm open to it.
EHL
> -Original Messag
Forwarded as per Eran's request.
A couple of corrections to my original email:
1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce
same origin policy).
2. When saying POST to '/authorize_callback' -- it may well be GET, if the
authorization server mishandles the request.
Hi Niv,
thank you for posting this to the list. I think you are right with your
threat description. One question: shouldn't the browser already prevent
the request to the authorization endpoint because of the same origin
policy (or CORS restrictions)?
Apart from that, a similar attack can be
Yes, I believe the vast majority of user-agents would block this kind
of request if it originated from a JavaScript XMLHttpRequest or such.
However, there are still scenarios in which a user-agent based client
could manipulate this vulnerability.
For example, the client could launch the GET reques
In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both
the line "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" and credentials in
the post body. For instance, the example from 4.3.2 is:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basi
Mike - I don't think that's true for the resource owner password
credentials flow that you showed below.
The Authorization header is authenticating the client, the
username/password POST body params represent the resource owner.
From: Mike Jones
To: "oauth@ietf.org"
Date: 26-07-11 02
The Authorization header in those examples is authorizing the client.
In 4.1.3 the /token URI requires HTTP basic authorization to access.
Section 2.4 talks about this more.
-Bob
On Mon, Jul 25, 2011 at 9:27 PM, Mike Jones wrote:
> In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examp
I believe those examples are okay.
The content in the post body is the grant while the HTTP Basic
Authorization header is the client authentication. They are two
different things.
On Mon, Jul 25, 2011 at 10:27 PM, Mike Jones
wrote:
> In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examp
There is nothing wrong with the examples.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, July 25, 2011 9:28 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Extra "Authorization: Basic" lines in examples
In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft
44 matches
Mail list logo
