Thanks Eran,
A question...
Is this text in 3.1.2.5 correct?
If third-party
scripts are included, the client MUST NOT ensure that its own scripts
(used to extract and remove the credentials from the URI) will
execute first.
MUST NOT ensure is a really odd construct. Maybe s/NOT//?
First, thanks all, but especially editors and chairs, for your
efforts on these. I'll be putting them on an IESG telechat
agenda very shortly.
That'll be for after the Paris meeting though, but only because
we have a monster 700 pages of I-Ds to go through for next week's
telechat due to
Thanks,
John B.
On 2012-03-07, at 7:57 PM, Eran Hammer wrote:
New text:
In order to prevent man-in-the-middle attacks, the authorization
server MUST implement
and require TLS with server authentication as defined by xref
target='RFC2818' / for
any request
You have read the spec., and the _only_ concrete thing it tells you
about the registers is the name of an email list. So you have to go
to the email archives and search for . . . what exactly? Different in
the three cases above, and in none of them is it obvious how to know
what counts as
In case anyone find it useful, here is a new OAuth 2.0 javascript library.
https://github.com/andreassolberg/jso
It would be useful for me if people tested it and reported any problems. I have
limited access to alternative OAuth 2.0 provider implementations, so I've only
tested a few
Barry Leiba writes:
You have read the spec., and the _only_ concrete thing it tells you
about the registers is the name of an email list. So you have to go
to the email archives and search for . . . what exactly? Different in
the three cases above, and in none of them is it obvious how to
OK, I now recognise a culture clash as the underlying point at issue,
so this spec. is the wrong place to address it.
Ah... so if the issue is how IANA makes registry information
available, then please go to the happiana mailing list (
https://www.ietf.org/mailman/listinfo/happiana ) and see if
Barry Leiba writes:
OK, I now recognise a culture clash as the underlying point at issue,
so this spec. is the wrong place to address it.
Ah... so if the issue is how IANA makes registry information
available
Precisely.
then please go to the happiana mailing list (
Hi Stephen,
I wanted to verify that, despite this state change, that it's still OK for me
to make the editorial change suggested by the WG to the Bearer spec to change
the b64token example.
Thanks,
-- Mike
-Original
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : Eran Hammer
Hi Mike,
On 03/08/2012 03:31 PM, Mike Jones wrote:
Hi Stephen,
I wanted to verify that, despite this state change, that it's still OK for me
to make the editorial change suggested by the WG to the Bearer spec to change
the b64token example.
Sure. Changes the WG want that don't conflict
Thanks that is better.
Without knowing the lifetime of the token these are per guess probabilities.
Effectively 128bits for a random value and 256bits for a HMAC or other
signature.
For tokens intended for handling by end-users it may be useful to give some
advice.
In general you don't want an
Yep. Forgot to drop the NOT. Want a new -25?
EH
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Thursday, March 08, 2012 2:32 AM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
Thanks Eran,
I pushed -25 just in case with this fix.
-Original Message-
From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Sent: Thursday, March 08, 2012 2:32 AM
To: Eran Hammer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
Thanks Eran,
A
Because we're in the middle of a chair change, we're having people
contact the chairs by sending email to Hannes and me. (1) This leaves
Derek out. (2) If you do this after the Paris meeting, you'll be
sending email to someone who's not an OAuth chair any more.
You can fix this by *always*
Hello all, I have a question about a possible use case of OAuth.
The standard use case which is outlined thoroughly in the spec, is a
client asking a resource owner for access to their information from the
resource server. But, what about the case where a client/resource owner
wants to share
David,
A use case that is similar to yours is described in
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02, section 3.8.
OAuth 2.0 does not directly support this use case.
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
If the refresh token is revoked, the client application would seem to have no
way to gain access to the third party resource again except through another
explicit user generated authentication. Is that correct? On some level this may
be desirable, since a compromised auth code also implies that
Sending to the full list.
-Original Message-
From: Roger Crew [mailto:c...@cs.stanford.edu]
Sent: Saturday, December 31, 2011 12:47 AM
To: Eran Hammer-Lahav; Adam Barth; Ben Adida
Subject: comments on oauth-v2-http-mac-00
Hi,
I have some comments on the now-expired http_hmac draft
19 matches
Mail list logo
