On Thu, Dec 1, 2011 at 6:27 PM, Stephen Farrell
wrote:
> On 12/02/2011 02:14 AM, Michael D Adams wrote:
>> Suppose an authorization server implements OAuth2 and has some
>> requirement that the MTI token type doesn't provide (as William Mills
>> suggested), so the se
On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
wrote:
> On 12/02/2011 01:38 AM, Michael D Adams wrote:
>> So an MTI token type + no client preference is equivalent to there
>> only existing one token type.
>
> Maybe.
>
> However, no MTI token type + no client prefer
I echo Justin Richer's comments.
On Thu, Nov 17, 2011 at 12:28 AM, Barry Leiba wrote:
> 1. Should we specify some token type as mandatory to implement? Why
> or why not (*briefly*)?
No. There's no mechanism in the spec for clients to request a
particular token type, so there's no opportunity f
On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones wrote:
> Given that people are clearly voting to change the bearer token scheme name,
> but that there is also significant discussion asking for “OAuth2” to be part
> of the name, I’d like to settle the matter by vote on the list. Please vote
> for one o
On Tue, Feb 8, 2011 at 1:45 AM, Anil Bhat wrote:
> Hi,
>
> I want to send user id as a parameter in my facebook app and want to
> return the same to keep track of the user who's connected to facebook
> from my app. I'm using Oauth2 methods - authorize_url and
> get_access_token. I tried to add par
On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav wrote:
> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
I vote #1.
In addition to the pros/cons Eran mentioned, it seems the simplest and
cleanest so will cause the least confusion.
William and others brought up backward compatib
On Fri, Jan 21, 2011 at 5:09 PM, Eran Hammer-Lahav wrote:
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
That link redirects me to -01
$ curl -I 'http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02'
HTTP/1.1 302 Found
Date: Sat, 22 Jan 2011 01:35:45 GMT
Server: Apache/
On Wed, Aug 4, 2010 at 10:20 AM, Oleg Gryb wrote:
> - Original Message
>> From: Michael D Adams
>> As Brian mentioned, the client-side component hosted on thirdparty.com
>> does get the access token in the User Agent flow. That means the
>> client-side
On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote:
> - Original Message
>> From: Michael D Adams
>> If> thirdparty.com never gets the access token, thirdparty.com can never
>> do anything on behalf of the user.
>>
> thirdparty.com never gets the access
On Tue, Aug 3, 2010 at 8:56 PM, Oleg Gryb wrote:
> I see your point, but let me try to eliminate the call to rpc_relay.html at
> all.
> After all, the ultimate goal is not to receive an access token, but a resource
> protected by that token.
The goal is to allow the user to delegate to thirdpart
The second to last paragraph in section 3 of draft-10 states:
> The authorization server validates the request to ensure all required
> parameters are present and valid. If the request is invalid, the
> authorization server immediately redirects the user-agent back to the
> client using the redir
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
>> “The client makes the following request at an arbitrary but reasonable
>> interval which MUST NOT exceed the minimum interval rate provided by
>> the authorization server (if p
On Sun, Jul 11, 2010 at 8:19 PM, Eran Hammer-Lahav wrote:
> My bad. I forgot to update the ABNF for the parameters.
>
> credentials = "OAuth" RWS access-token RWS [ 1#auth-param ]
Thanks. I suppose it should be
credentials= "OAuth" RWS access-token [ RWS 1#auth-param ]
which I'll add t
According to section 5.1.1, commas, equal signs, and quotation marks
are all allowed in the access-token. How do I parse the following
Authorization header?
Authorization: OAuth vF9dft4qmT,foo="bar"
1. The access-token is 'vF9dft4qmT', and the value of some extension
parameter 'foo' is 'bar'.
2.
On Wed, Jul 7, 2010 at 1:11 PM, Eran Hammer-Lahav wrote:
> Thanks. Browser security is not my area.
>
> It seems to me that this must be documented as all the examples I have seen
> for such scripts did not include any such security measures.
Nor is it mine. I know some techniques for cross-orig
On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav wrote:
> The issue is that it is hard (or even impossible) to prevent another
> user-agent client from imitating another user-agent client. A pre-registered
> redirection URI does very little to help. In most cases, such a URI will
> point to a we
On Wed, Jul 7, 2010 at 10:31 AM, Marius Scurtescu wrote:
> On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams wrote:
>> Actually, for a small minority of WordPress sites wanting to enable
>> OAuth (those not supporting so called "pretty permalinks"), the
>> WordPress
On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams wrote:
> WordPress uses query parameters. A WordPress plugin that enables
> OAuth, though, would have to register new URL handlers with WordPress
> to act as the token and end-user authorization endpoints. Having done
> so, the plugi
On Tue, Jul 6, 2010 at 10:24 PM, Marius Scurtescu wrote:
> On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams wrote:
>> For section 6.2 (query parameters on the end-user authorization and
>> token endpoints), this should not be an issue for WordPress.
>>
>> For sec
>> If there are actual requirements for using OAuth 2.0 with such systems, we
>> should discuss these, but it would be silly for us to architect our work
>> based on the limitations of random platforms.
>
> I don't think these are random at all. MediaWiki, Drupal, WordPress,
> to name a few, are ma
On Wed, Jun 30, 2010 at 10:08 PM, Eran Hammer-Lahav wrote:
> 1. Use dashes throughout
> 2. Use underscores for all parameter names (headers included), dashes for
> all values
> 3. Use underscores throughout
3
___
OAuth mailing list
OAuth@ietf.org
https:
+1
On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav wrote:
> After taking a break from our previous debate(s) on the issue of which
> response format to support, I would like to suggest the following:
>
> - Support a single response format (including in the user-agent fragment)
> using JSON.
On Tue, Jun 8, 2010 at 3:10 PM, Eran Hammer-Lahav wrote:
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
>> Yaron Goland
>> Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of
>> TLS/SSL?
>
> Is it ok to require TLS 1.2?
>
>> To me this text imp
Three things about draft-05's new format parameter.
1. Error Response:
http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.2
Presumably, the error response format should reflect the format
parameter passed by the client.
Proposed Text (wording taken from
http://tools.ietf.org/html/dr
I'm interested in the possibility of requiring clients to use
cryptographic tokens.
Context: I'm writing a WordPress plugin to handle OAuth 2.0
authentication. Small one-off WordPress sites (probably on a shared
host) likely cannot use SSL. Such a site would necessarily be
non-compliant because
25 matches
Mail list logo
