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 (oaut
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
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 O
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 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* using
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,
>
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 E
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
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 wit
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
D
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 Message---
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 (
> https://www.
> 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
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 h
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 of
> 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
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 target='RFC2818' /> for
> any request sen
Barry Leiba writes:
> Henry says...
>>> No, I appreciate that you want to use registered short names in
>>> the protocol, that's just fine. My problem is that you have left
>>> users, developers etc. with no way to discover what shortnames
>>> have been registered short of a non- trivial and err
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 outgoin
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//
20 matches
Mail list logo
