If you have any more feedback for -09 please submit today. I plan to publish
-10 by Monday which will be the last draft for 4 weeks, and hopefully a draft
we can declare as stable for implementation. So if there is anything you really
want to see changed, today is your last chance for a while.
I just finished the first version of my I-D on multiple access tokens
and would like to initiate a discussion whether the WG sees this as a
potential WG item.
Due to the pre-meeting cutoff date for submitting new drafts, I cannot
submit it to the IETF site now. Since I don't want to lose
Hi OAuthers,
First of all, I think I should introduce myself. I work at Facebook on the
Platform team (anything not facebook.comhttp://facebook.com). Before this I
was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth
applications and libraries, both at Yahoo and in
I agree we don't want to end up like other protocols that were too generic. :)
The use case I am arguing for is sending encrypted tokens. Higher levels of
assurance require this and various people brought this up as a requirement when
WRAP was presented at IIW 09B.
-- Dick
On 2010-07-10, at
On 2010-07-10, at 1:42 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-10, at 1:21 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt dick.ha...@gmail.com wrote:
* the signature comes before the payload
* we
On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt dick.ha...@gmail.com wrote:
Obviously anything besides what you need for your use case adds complexity.
The question is: are you willing to accept some complexity so that it works
for use cases than yours? If not, then perhaps you should just define
The term access grant in the -09 spec is a bit odd. Normally
access grant or permission grant would refer to a specific policy
decision made by a resource owner.
But that's not how the -09 spec uses the term. The -09 spec refers to
authorization codes and assertions as access grants. Again,
Hey folks -
The client credentials flow should never return a refresh token, for
the following reasons:
- it's never necessary
- it's a security problem
- it's inefficient
- it's confusing
I'll go over each of those points in detail, but here are the changes
to the spec I'd like to see.
Page
Hi folks -
Draft 6 section 2.9.1 had a section called Client Requests Access
Token: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34.
In this flow a client presented a client_id and client_secret, and got
an access token in return.
I can't find the corresponding section in draft 7. It
How about write some new text about what refresh tokens are for and when they
should be issued. I think this can benefit from its own section. The rest is
mostly editorial.
EHL
On 7/10/10 8:09 PM, Brian Eaton bea...@google.com wrote:
Hey folks -
The client credentials flow should never
See 'grant_type=none' described in 4.1.
EHL
On 7/10/10 8:12 PM, Brian Eaton bea...@google.com wrote:
Hi folks -
Draft 6 section 2.9.1 had a section called Client Requests Access
Token: http://tools.ietf.org/html/draft-ietf-oauth-v2-06#page-34.
In this flow a client presented a client_id and
The draft 9 spec has no efficient way for a javascript client to
request a verification code. The spec creates extra client-to-server
round trips. There is also some inaccurate description of the
properties of the profile. The problems are located in section 1.4.2:
There is no user-agent flow anymore. There is a profile (of the generic
endpoints described in the rest of the spec). Draft -09 added the ability to
get both an authorization code and an access token. Your description makes it
sound like draft -09 broke something when it was never proposed that
I think it would be a good idea to return to the draft 6 organization.
Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no interruption. Each step showed what a client should send, and what
an authorization
On Sat, Jul 10, 2010 at 9:05 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
There is no user-agent flow anymore.
Yeah. That's a bug. =(
The request was to allow it to
obtain both when using a web-based component together with the user-agent.
Right, this didn't use to be possible, but
Eran,
Is the draft 10 spec going to outline what characters are allowed in the
access token? And if not (or if all characters are allowed), is it going to
include details about (or a reference to a doc about) how to properly escape
the access token when specifying it in the HTTP Authorization
16 matches
Mail list logo
