Hi Zachary,
that's fine with me.
regards,
Torsten.
Am 08.04.2010 23:24, schrieb Zeltsan, Zachary (Zachary):
Torsten,
I really like this use case. I think it ought to be documented on its own.
(But please let me know if you disagree and thing that it is a subset of
another use case.)
I als
+1 no restriction, please
256 is much too short
Am 10.04.2010 07:16, schrieb Eran Hammer-Lahav:
I would argue that for the spec to provide a token size limit that is
greater than 255 would cause more harm than good. This is not to say I
am supporting the 255 limit (I take no position on the ma
Its a more complicated spec in both detail and how signatures are created.
The fact that the URI or body includes both resource parameters and
token/signature parameters makes it necessary to parse and sort the parameters,
deal with encoding, etc. If we limit signed request to the header, then a
I would argue that for the spec to provide a token size limit that is greater
than 255 would cause more harm than good. This is not to say I am supporting
the 255 limit (I take no position on the matter - yeah, that happens rarely).
If the spec provided a 4K limit, client libraries are likely to
On 4/9/10 1:58 PM, "Evan Gilbert" wrote:
>
>
> On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav
> wrote:
>>
>>
>>
>> On 4/9/10 8:29 AM, "Evan Gilbert" wrote:
>>
>>>
>>>
>>> On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav
>>> wrote:
On 4/8/10 9:17 PM, "Eva
Anyone willing to work with me to produce non-ascii diagrams for the HTML
spec? I'm open to anything from some fancy HTML5 canvas to a simple PNG...
The ascii flows are fine for the RFC canonical text version, but they are
pathetic for an HTML spec produced in 2010...
I am looking for some help o
(+apps-discuss as this is of general interest to the area)
On 4/9/10 1:26 PM, "Chuck Mortimore" wrote:
> A number of the modern application platforms (Android, iPhone, iPad) have
> support for registering custom url schemes for native applications.This
> allows them to receive callbacks from
However, this doesn't address my earlier use case of a signed, cross-
domain JSONP call, especially if it's sitting on a non-HTTPS page; I
need to make a non-HTTP XHR request to obtain a (signed or tokenized)
URL to include in my
+1
Not sure If it¹s possible for different SPs to agree on the specs for each
mode, but as we learned from implementing OpenID, it¹s very useful for the
client to have an interface to indicate to the AS how the UI should be
rendered.
At least in Yahoo¹s case, we¹d like to see all the display mod
I think a good precedent would be to use the HTTP Cookie size limit, which
is 4KB.
An OAuth Access Token is like an HTTP Authorization cookie. They're both
bearer tokens that are used as a credentials for a client to access
protected resources on behalf of the end user.
All Oauth clients have to
On Fri, Apr 9, 2010 at 10:43 AM, Eran Hammer-Lahav wrote:
> I’m opposed to having both any parameters and a state parameter. Pick
> one. OAuth 1.0a allowed any client-specific parameter in the callback. The
> argument for adding a state parameter was to increase interop but that is
> only true if
I would actually like to see the inclusion of reference tokens here also, I do
think that the 255 character limit is too restrictive and needs to be revisited.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Eaton
Sent: Friday, April 09,
On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/9/10 8:29 AM, "Evan Gilbert" wrote:
>
> >
> >
> > On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav
> > wrote:
> >>
> >>
> >>
> >> On 4/8/10 9:17 PM, "Evan Gilbert" wrote:
> >>
> >>>
> >>>
> >>> On Thu, Apr 8, 2010 at 12:22
A number of the modern application platforms (Android, iPhone, iPad) have
support for registering custom url schemes for native applications.This
allows them to receive callbacks from web browsers, without resorting to copy
paste, or window title polling.For instance, the authorization s
On Fri, Apr 9, 2010 at 3:14 AM, Luke Shepard wrote:
> Let's finish off the thread on token length limits.
>
> In summary, David Recordon proposed a length limit of 255 characters due to
> database length limits ("blobs versus shorter and indexable types such as
> varchars"). Several people were
On Fri, Apr 9, 2010 at 11:34 AM, Luke Shepard wrote:
> Let me see if I understand this attack. Let's say Evil Eve goes to
> Example.com. Example.com redirects her to:
>
> https://facebook.com/oauth/authorize?client_id=XXX&type=web_callback_access_request&callback=http://example.com/oauthcallback
(I'm looping the IETF mailing list into this discussion since I think it's
useful)
> Luke wrote:
>> I think the callback_url is superfluous in Web Callback Flow (D).
>> The session fixation attack can't happen because the verification_url will
>> only appear to the owner of the callback url - so
On 4/9/10 8:29 AM, "Evan Gilbert" wrote:
>
>
> On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav
> wrote:
>>
>>
>>
>> On 4/8/10 9:17 PM, "Evan Gilbert" wrote:
>>
>>>
>>>
>>> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav
>>> wrote:
On 4/7/10 9:20 PM, "Eva
I'm opposed to having both any parameters and a state parameter. Pick one.
OAuth 1.0a allowed any client-specific parameter in the callback. The argument
for adding a state parameter was to increase interop but that is only true if
it comes instead of custom parameters.
EHL
On 4/9/10 7:37 AM,
In practice this is the same as logging in which I expect to require SSL
anyway. Signed or not, attackers should not be able to login to your email
account simply by using a MITM attack when you click on your IM client. So SSL
is required already.
EHL
On 4/9/10 7:30 AM, "George Fletcher" wro
On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/8/10 9:17 PM, "Evan Gilbert" wrote:
>
> >
> >
> > On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav
> > wrote:
> >>
> >>
> >>
> >> On 4/7/10 9:20 PM, "Evan Gilbert" wrote:
> >>
> >>> Authorization servers in the OAuth Web C
On Fri, Apr 9, 2010 at 7:37 AM, Evan Gilbert wrote:
>
>
> On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>
>> On 4/8/10 11:11 PM, "Evan Gilbert" wrote:
>>
>> >>
>> >>
>> 2. Section 2.1: "The authorization endpoint advertised by the server
>> MUST NOT include a query
Yes, it does, thanks!
It makes me think that the Security Considerations text should include
something along the lines that OAuth does not exclude (or maybe even
"encourages" instead of "does not exclude") multi-factor authentication,
which can mitigate cases where the present security mechani
On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/8/10 11:11 PM, "Evan Gilbert" wrote:
>
> >>
> >>
> 2. Section 2.1: "The authorization endpoint advertised by the server
> MUST NOT include a query or fragment components as defined by
> [RFC3986] section 3." Why
Yes, this is possible, though to be secure it should really happen over
SSL which is less of a requirement for a signed request.
I guess the main question is whether we really need to remove the
signature related parameters from URL and only allow them in the
Authorization header. For signed r
Can you submit a proposal?
On Apr 9, 2010, at 13:25, "Luke Shepard"
mailto:lshep...@facebook.com>> wrote:
I am still not sure why we *need* discovery in order to just add a “display”
parameter to the spec.
I would like to see a set like the following supported:
- popup
- f
I am still not sure why we *need* discovery in order to just add a "display"
parameter to the spec.
I would like to see a set like the following supported:
- popup
- fullpage
- touch (for smart phones (like iPhone)-like phones)
- mobile (for older-mobile p
Let's finish off the thread on token length limits.
In summary, David Recordon proposed a length limit of 255 characters due to
database length limits ("blobs versus shorter and indexable types such as
varchars"). Several people were opposed to the 255 length limit. However, there
was general f
In the Web Callback Flow, section 3.4.1.2 requires the client to pass the
"callback" parameter back a second time.
Why?
I believe this is supposed to be there to prevent session fixation attack, but
I don't see an attack vector where the verification code is not sufficient to
prevent things. I
Its a growing list... :-)
If the client can ask for a refresh token, why not also let it ask for a
secret in each flow, and a username, and specific UI, etc. At some point we
cross a line and the protocol becomes complex (even if rich). I'm asking
where that line is, and if this qualifies as wo
On Fri, Apr 9, 2010 at 1:01 AM, Eran Hammer-Lahav wrote:
> On 4/8/10 4:25 PM, "Marius Scurtescu" wrote:
>
>> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav
>> wrote:
>>> This seems reasonable, but it does add more complexity for the client.
>>
>> True, but not that much. Just an extra reques
As far as I understand, this use case could also be implemented using
bearer tokens. Am I wrong?
I assume the benefit of using signed GET requests is a better protection
against abuse of the token if the URL is spread via log files or
Referer-Headers. But this measure obliges the receiver to i
would you please outline a example?
Am 08.04.2010 18:38, schrieb David Recordon:
Agreed with Eran. GET parameters certainly make exploring APIs easier.
On Thu, Apr 8, 2010 at 7:31 AM, Eran Hammer-Lahav wrote:
While I agree that the spec would be much cleaner with only HTTP header
support,
On 4/8/10 11:11 PM, "Evan Gilbert" wrote:
>>
>>
2. Section 2.1: "The authorization endpoint advertised by the server
MUST NOT include a query or fragment components as defined by
[RFC3986] section 3." Why do we disallow query parameters? If we want
to enforce strict match
@Brian: I CC'd you because you edit the security considerations document.
I rather add support for query and post parameters (we are really talking
about a single parameter, oauth_token, outside the HTTP header), and in a
few year deprecate it in OAuth 3.0. The benefit of these features is that
35 matches
Mail list logo
