- Explain that the separation between the authorization server and
resource server is out of scope
Why is this out of scope? I consider this a major improvement over
Oauth 1.0.
regards,
Torsten.
Am 15.06.2010 um 08:35 schrieb Eran Hammer-Lahav :
- Explain that the separation between th
As long as:
- You can provide a URI identifier for the assertion format you are going to
use, and
- The authorization server can do something useful with the assertion provided
and decide if it should grant an access token
Then sure, you can use the assertion flow for utilizing any other trust
During the OAuth WG interim meeting, the group spent a considerable amount of
time going over draft -05 and listing issues with the text and protocol. Since
the draft is now significantly different, I want to go over this and identify
the issues resolved and those still open (before it is too la
+1
On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
> On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott wrote:
>> For an application I'm building, the installed client app will have
>> intermittent windows of time where it can obtain a (non-OAuth) assertion for
>> user identity. During this time, it
On 2010-06-14, at 9:41 PM, Evan Gilbert wrote:
>
> If a response from the AS is untrusted, there are much bigger issues at
> stake. ... or am I missing an obvious attack where random JSON would get sent
> to the Client?
>
> For the web server flow, you know the AS server you called and can re
>
>
> If a response from the AS is untrusted, there are much bigger issues at
> stake. ... or am I missing an obvious attack where random JSON would get
> sent to the Client?
>
For the web server flow, you know the AS server you called and can
reasonably trust the data.
For the user agent flow, a
On Sun, Jun 13, 2010 at 5:55 PM, Eran Hammer-Lahav wrote:
> To be clear, you are +1 on using only JSON for server responses on the
> token endpoint?
>
Yes, +1 on JSON responses for token endpoint.
>
>
> EHL
>
>
>
> *From:* Evan Gilbert [mailto:uid...@google.com]
> *Sent:* Sunday, June 13, 2010 11
> Since refresh token is only issued to clients capable of directly interacting
> with the authorization server, is there a reason why the endpoint cannot use
> DELETE instead of a POST with a parameter?
>
> DELETE /token HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-fo
On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott wrote:
> For an application I'm building, the installed client app will have
> intermittent windows of time where it can obtain a (non-OAuth) assertion for
> user identity. During this time, it seems appropriate for it to use the
> assertion flow to
First, the spec says "SHOULD NOT issue a refresh token" which means, don't do
it unless you have to. But what stops the client from keeping the same
assertion and reusing it later?
As for using other methods for providing an assertion, you need to be more
specific about what you have in mind. B
For an application I'm building, the installed client app will have
intermittent windows of time where it can obtain a (non-OAuth) assertion for
user identity. During this time, it seems appropriate for it to use the
assertion flow to obtain an OAuth authorization so that it can impersonate
the us
This is the second half of the big rewrite. I changed the entire introduction
to better explain the new model, as well as cleaned up the rest of the new
work. This is still not a smooth specification, but I think the general
structure is starting to come through. I feel much better about the cur
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
How would you propose this as a generic mechanism for the token endpoint as
defined in -08 (or -07)?
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Thursday, April 22, 2010 5:45 PM
> To: oauth@ietf.org
> Subject:
Done.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck
Mortimore
Sent: Monday, June 14, 2010 4:53 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Error Code for username/password flow
There doesn't seem to be a proper error code to use with the Username/Password
flow.
There doesn't seem to be a proper error code to use with the Username/Password
flow. If the client credentials are wrong "incorrect_client_credentials" is
used. Nothing is specified if the end-user credentials are incorrect.
Suggestion: "invalid_user_credentials"
-cmort
Both of those scenarios could also be bad 1.0 calls where a 400 error
needs to be thrown due to missing a required parameter.
So worse case is that every single parameter from a 1.0 calls needs to
be checked that at least one of them exists in the call and then its
still possible that it could b
+1 (JSON in direct response, separate discussion on redirect response)
On Mon, Jun 14, 2010 at 10:15 AM, Brian Eaton wrote:
> On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav
> wrote:
> > So far we have 16 people supporting using JSON as the only response
> format
> > for the token endpoint
Since refresh token is only issued to clients capable of directly interacting
with the authorization server, is there a reason why the endpoint cannot use
DELETE instead of a POST with a parameter?
DELETE /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlenco
As stated previously the easy way to determine OAuth 1.0 vs 2.0 without
using negative assertions is to check for the presence of
oauth_signature_method
On Mon, Jun 14, 2010 at 1:09 PM, David Recordon wrote:
> It's easy to detect version when calling a protected resource. In
> OAuth 2.0 you only
It's easy to detect version when calling a protected resource. In
OAuth 2.0 you only have one token parameter whereas 1.0 has a variety
of parameters including a signature.
--David
On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards wrote:
> Wouldn't it make sense to require the oauth_version paramet
I would prefer a frequency of once a week.
regards,
Torsten.
Am 14.06.2010 19:14, schrieb Eran Hammer-Lahav:
I am now making daily changes to the draft. I check these changes in daily
(sometimes more) to my github account [1] but I'm not clear how often do people
here wants me to submit those
Yeah. I need to finish the big rewrite before adding new stuff. I plan to get
this done this week.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Paul Madsen
> Sent: Monday, June 14, 2010 10:20 AM
> To: OAuth WG (oauth@ietf.org)
> S
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Monday, June 14, 2010 11:23 AM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav
>
Am 14.06.2010 19:10, schrieb Eran Hammer-Lahav:
Not so much text as details.
Does revoking the refresh token also revokes any access token issued with it?
no (or optionally). It's not easy to implement in conjuction with
self-contained tokens. I would prefer to use short living access tok
On Mon, Jun 14, 2010 at 8:23 AM, Andrew Arnott wrote:
> And apparently now the user-agent flow can receive a
> verification code as well as an access token? It's unclear what that's for
> or how that's used.
Here's the thread where Brian Ellin proposed the verification code on
the user-agent flo
On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> Adding a verification code to the user-agent flow was suggested on this list
> and received nothing but support. It was suggested as a solution to a
> Twitter use case. Once that is added in, the two flows only differ in how
> the respons
Hi Eran, you indicated last week there would be a first cut of an
extensibility model in 07.
Deferred to 08?
Thanks
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav wrote:
> So far we have 16 people supporting using JSON as the only response format
> for the token endpoint with no objections. Draft -07 reflects this change. I
> am
> considering this matter closed, but if someone has a late objection, feel
I am now making daily changes to the draft. I check these changes in daily
(sometimes more) to my github account [1] but I'm not clear how often do people
here wants me to submit those as I-D revisions. Frequent submission makes it
harder for people to read and provide feedback because there alw
Not so much text as details.
Does revoking the refresh token also revokes any access token issued with it?
Do we need a way to revoke other authorization grants, such as a verification
code?
Do we need a way to revoke an individual access token?
Does revoking means the end-user has to grant autho
Since the secret is bound to the token anyway, changing the access token will
break the signature (unless you know that two tokens have the same secret -
which implies you know the secret too).
I can add it but I'm not sure how important it is.
EHL
> -Original Message-
> From: oauth-bo
So far we have 16 people supporting using JSON as the only response format for
the token endpoint with no objections. Draft -07 reflects this change. I am
considering this matter closed, but if someone has a late objection, feel free
to raise it.
As for using JSON in the fragment or query of th
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, June 14, 2010 7:20 AM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> I disagree. I don't think it's redundant, I think it's a clarifying
+1 on JSON in response bodies
-1 on JSON in URL query parameters or fragments.
Dirk.
On Sun, Jun 13, 2010 at 2:46 AM, Evan Gilbert wrote:
> -1
>
> I disagree very strongly with this approach if I'm understanding
> correctly. Let me paraphrase to make sure I understand:
>
> All responses, even t
Hi Kevin,
out of curiosity: why do you experience this problem with pre-paid users
only?
regards,
Torsten.
Am 14.06.2010 13:54, schrieb Kevin Smith:
Thanks for the good question Torsten - and thanks to Igor for
answering it better than I could :) . We are looking at GBA within the
OneAPI gr
+1
Am 14.06.2010 16:13, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Hi all,
Those who attended the last IETF meeting noticed that the actual working
group slots are quite short (around 2 hours). The feedback I got was
that this does not leave us with enough time to get work done. I
understand
Why client developers? How does it make their life easier?
An approach I'm more comfortable with is to redefine 'type' as the type of
authorization grant provided: refresh_token, user_basic, verification_code,
assertion. And if we use the name 'type', I would change the 'type' parameter
on the
Adding a verification code to the user-agent flow was suggested on this list
and received nothing but support. It was suggested as a solution to a Twitter
use case. Once that is added in, the two flows only differ in how the response
is delivered and the presence of an access token in the respon
Wouldn't it make sense to require the oauth_version parameter under 2.0
for resource calls so that the two versions can be distinguished?
Rob
Paul Lindner wrote:
If you're routing requests with a load balancer it's not so trivial.
Instead of a substring match you're talking about a regex wit
I find the combination of the web server and user agent flows for end user
authorization unnatural -- particularly poignant in the success response,
which has 4 parameters -- but one flow MUST have no more than 2, and the
other must have 3. And apparently now the user-agent flow can receive a
veri
+1 for the type parameter.
Our internal server and client developers would both prefer it.
-cmort
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Justin
Richer [jric...@mitre.org]
Sent: Monday, June 14, 2010 7:20 AM
To: Eran Hamme
I disagree. I don't think it's redundant, I think it's a clarifying
piece of information that makes it completely unambiguous what the
client is expecting to happen. On the server side, a single switch is a
much simpler and less error-prone dispatch structure than a set of "if
this-and-that paramet
Hi all,
Those who attended the last IETF meeting noticed that the actual working
group slots are quite short (around 2 hours). The feedback I got was
that this does not leave us with enough time to get work done. I
understand that argument and acknowledge that not everyone wants to
attend a punch
Thanks for the good question Torsten - and thanks to Igor for answering it
better than I could :) . We are looking at GBA within the OneAPI group but
as you say the low deployment base may be a problem.
Best,
Kevin
On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynberg <
igor.faynb...@alcatel-lucent.com>
45 matches
Mail list logo
