I'd like to keep form-encoded inputs. I think it makes sense to use a
well-established key-value mechanism, and the asymmetry at play here is
what the web is made of (post a form, get HTML/XML/JSON/whatever).
Along those lines, I'd actually like to relax the restriction of using
"POST" and allow f
How about "approval", as in delegation approval or association approval (since
the resource owner is approving or consenting to the association of these two
services on the owner's behalf for delegated access purposes, with specific
tokens later representing specific access authorizations)?
Proxies and caches.
EHL
On Jul 12, 2010, at 8:48, "Justin Richer" wrote:
> I'd like to keep form-encoded inputs. I think it makes sense to use a
> well-established key-value mechanism, and the asymmetry at play here is
> what the web is made of (post a form, get HTML/XML/JSON/whatever).
>
>
Yep. I should not write ABNF after a day of editing.
EHL
On Jul 12, 2010, at 1:39, "Michael D Adams" wrote:
> 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#aut
I wrote this draft last month based on discussions on the mailing list, the
OpenID user experience extension (which Facebook, Google, and Yahoo! have
deployed), and some OAuth 2.0 implementation experience from Facebook. It
defines language and display preferences which the client can include in
re
Now that core is pretty stable, we should start adding a few new WG items. This
is a no brainer.
EHL
On 7/12/10 12:51 PM, "David Recordon" wrote:
I wrote this draft last month based on discussions on the mailing list, the
OpenID user experience extension (which Facebook, Google, and Yahoo! h
Approval feels like something temporary that happens in a specific moment,
unlike grant or credential which are 'issued'.
EHL
On 7/12/10 6:39 AM, "Eve Maler" wrote:
How about "approval", as in delegation approval or association approval (since
the resource owner is approving or consenting to
The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access
tokens has come up on the list a few times. Attached is a draft assertion
format which allows a client to trade an OAuth 1.0 token/secret pair for an
OAuth 2.0 access token. The assertion format is a JSON object with values
for
.David,
> I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a working
> group document
I disagree. This shouldn't be a working group document. It should be moved into
the core.
The 2 parameters it defines (language and display) should be moved to the core
OAuth doc now t
Obviously I'm fine with this being merged into core if that's what the group
wants to do. :)
On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> .David,
>
>
>
> > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a
> working group documen
I think it belongs in a separate spec (even if at the end if might mean more
work for others and me). I don't think the UX bits are well understood or enjoy
enough experience to become part of core. They also tend to change often as the
state of the art in UX evolves.
With -10, I am going to ta
As of -10, the Authorization Request Parameters are required to be
passed as part of the Authorization Request URI query component.
I would like to see it relaxed a bit so that they do not have to be a
part of the URL but can be passed by reference.
In the proposal that I have submit a while ago,
Draft 10 has the following sentence in section 4.1.4:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
"The authorization server MAY issue a new refresh token."
That carries a surprising amount of baggage. I suggest removing the
sentence, or changing it to MUST NOT, pending a disc
Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
Calling access tokens "shared symmetric secrets" is misleading,
because if they are implemented well the authorization server and
protected resource do not store a copy of the secret.
Instead they store a one-way hash of the t
Section 5 does not appear to list any authentication method that the
server is required to support:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.
How about resource servers MUST support the Authorization header and
may support other methods?
_
Ah, never mind, this got added to draft-10 already. Thanks.
On Mon, Jul 12, 2010 at 10:42 PM, Brian Eaton wrote:
> Section 5 does not appear to list any authentication method that the
> server is required to support:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.
>
> How about re
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1
The "expired_token" error code doesn't scale well and won't be
implemented reliably. It should be merged with "invalid_token".
Suggested language:
invalid_token
The access token provided is invalid. Resource servers
SHOUL
On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav wrote:
> I think the way to solve it is to make them more detailed and normative.
> This will retain the general framework as current specified, but will
> provide a reference-able description of useful profiles. This will also make
> it easier to
18 matches
Mail list logo
