http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/
Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1 to accepting only HTTP POST and preventing cross-site posting.
On Apr 2, 2010, at 10:20 AM, Marius Scurtescu wrote:
> On Fri, Apr 2, 2010 at 8:53 AM, Brian Eaton wrote:
>> On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom wrote:
>>> The Auth server should also check for the presence of an HTTP Refer
Even if the auth server is using redirects for user simplicity, it can still
comply with the referer-checking requirement by having the simple URL
(http://google.samsung.com) pass its referer as a GET param to the actual
complex URL (https://www.google.com/accounts/OAuthAuthorize?client_id=12389
There are times when a resource may have different scope for different kinds of
access. realm != scope
On 2010-04-02, at 2:45 PM, Igor Faynberg wrote:
>
>
> I don't see any problem at all.
>
> Igor
>
> David Recordon wrote:
>> Assuming that this is mean to replace the scope parameter?
>>
>>
I don't see any problem at all.
Igor
David Recordon wrote:
Assuming that this is mean to replace the scope parameter?
On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an
Assuming that this is mean to replace the scope parameter?
On Fri, Apr 2, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> This is half baked but I wanted to get people's reaction:
>
> Clients tries accessing a resource with or without an access token:
>
> GET /resource/1 HTTP/1.1
> Host: server.exa
On Fri, Apr 2, 2010 at 12:00 PM, Eran Hammer-Lahav wrote:
> Because of how we send parameters. Most of the problems we had with
> 1.0 involved encoding issues. We just need to find a good way of
> explaining it.
>
> These are the characters allowed in Uris and form encoded bodies.
Of course, but
On 4/2/10 10:35 AM, Marius Scurtescu wrote:
> On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav
> wrote:
>> The current draft allows the following characters:
>>
>> value-char = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"
>>
>> Which means a utf-8 string will need to be encoded somehow. Shoul
Because of how we send parameters. Most of the problems we had with
1.0 involved encoding issues. We just need to find a good way of
explaining it.
These are the characters allowed in Uris and form encoded bodies.
EHL
On Apr 2, 2010, at 12:35, "Marius Scurtescu"
wrote:
> On Thu, Apr 1, 2
Hi Eran,
A few more comments:
1. Only one endpoint. While I think collapsing the access token and
refresh token URLs into one URL was a good think, keeping the user
authorization as a separate URL could be beneficial. I think there
should be 2 endpoints defined: access token and user authorizatio
On Fri, Apr 2, 2010 at 8:53 AM, Brian Eaton wrote:
> On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom wrote:
>> The Auth server should also check for the presence of an HTTP Referrer.
>> There should not be a referrer, since the user should not have clicked on
>> anything to have landed on the screen
>
Agreed on Base64, however the SAML already specifies this at it's encoding for
web profiles, so we'll get the most reuse out of existing infrastructure by
using it.
I will work on an example - we should be able to make some sound decisions
about how best to deal with it once we have somethin
On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav wrote:
> The current draft allows the following characters:
>
> value-char = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"
>
> Which means a utf-8 string will need to be encoded somehow. Should it be
> percent-encoded? Something else?
Why do we
Presumably, the realm was used to discover the token issuance endpoints.
Why wouldn't the discovered URL of the access token endpoint dictate
realm, and why can't the realm then be implicit beyond discovery?
-Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Scop
This is half baked but I wanted to get people's reaction:
Clients tries accessing a resource with or without an access token:
GET /resource/1 HTTP/1.1
Host: server.example.com
The server replies with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm='example'
Clients requests an
The problem with base64 (even the uri safe flavor) is the paddind
character (=) is not allowed without percent encoding. This gets messy
without clear encoding process.
The example below show that the profiles are likely to be much longer
than the flow itself, raising my question of whether
On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom wrote:
> The Auth server should also check for the presence of an HTTP Referrer.
> There should not be a referrer, since the user should not have clicked on
> anything to have landed on the screen
I don't think this one is going to work in practice. Manu
Other profiles will be required. The only point is to give these profiling
specs clear guidelines on how they should approach the problem.
In any case, I get your point about what you want included in the core
specification and why. I'll try and draft a proposal for the SAML format over
the
Other profiles will be required. The only point is to give these profiling
specs clear guidelines on how they should approach the problem.
In any case, I get your point about what you want included in the core
specification and why. I'll put forth a proposal for the SAML format.
-cmort
___
The format would be specified by a profilie.For instance, a SAML profile
might define:
assertion_format=urn:oasis:names:tc:SAML:2.0:cm:bearer
assertion={SAML 2 bearer assertion, optionally wrapped in a SAML response,
Signature must cover the assertion and can be inherited from the Response
For SAML it should be Base64 encoded.
-cmort
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, April 01, 2010 10:10 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] SAML A
The OAuth implementation at Deutsche Telekom uses a non-standard
parameter "serviceId" to identity the protected resource the client
wants to access. The client passes such an id as parameter when
requesting a token. The authorization server knows all services it
issues tokens for. The service
22 matches
Mail list logo
