As a substantive comment on the draft (I'm in favor of it being a working
group item), it is not clear whether "Basic" is a required value on the
"Authorization" header included in a revocation request. In some scenarios
(particularly three legged), the client app will not possess the username
and
why is it neccessary to duplicate the OAuth request parameters?
Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in
openID Connect to make signed requests to the Authoriz
The Connect use case was a bit different for needing a id_token however your
proposal would work if being less efficient for the code flow.
However in the implicit flow you can't get a refresh token so the only option
is to make the user go through multiple authorizations, or return multiple
to
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in openID
Connect to make signed requests to the Authorization server.
We do have the issue that parameters in the signed/encrypted request
necessarily duplicate the
HI Torsten,
I and John just refreshed the I-D to be more in-line with what we do with
OpenID Connect.
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01
As you point out, this would solve the duplication / non-standard behavior
that OpenID Connect requires.
Cheers,
Nat
On Thu, Oct 27,
Actually, I think we need to document the use case.
Igor
On 10/25/2011 7:08 PM, Dave Rochwerger wrote:
Is separating this out into 2 different tokens, really the best way to
solve your use case?
It sounds to me that you simply want to track/log the two types of
accesses differently, which ca
Should a brief explanation of this be added to the Threat Model and
Security Considerations document? Or does anyone even agree that this
can be a problem?
Regards,
Andre DeMarre
On Tue, Oct 4, 2011 at 11:32 AM, André DeMarre wrote:
> I've not seen this particular variant of phishing and client
First, I think that this threat should be elevated to something more than
a threat because it is a fundamental assumption of the protocol that the
browser is trustworthy. I have heard far too many people on this list say
that that's silly because it is "obvious" but it is not obvious to the
uninit
Hi all,
the new version of the security document is mostly dedicated to the
alignment with the core draft -22.
* Alignment of terminology with core draft 22 (private/public client,
redirect URI validation policy, replaced definition of the client
categories by reference to respective co
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 : OAuth 2.0 Threat Model and Security Considerations
Author(s) : Torsten Lodderstedt
Hi,
Am 26.10.2011 05:41, schrieb Bob Van Zant:
I'm going to reiterate what has already been said.
OAuth already supports what you're trying to do. Just request a token
twice, the first time request it with a scope or scopes that allows
these special operations. The second time request it with
Hi Nat,
I think your proposal would be a useful OAuth enhancement. A JSON-based
request format would allow for more complex requests (e.g. carrying
resource server URLs and corresponding scope values ;-)).
Please note: I also think the way this mechanism is introduced and used
in the current
Thanks, Bob, you're right and I withdraw my request to allow the return of two
tokens.
However, I'm not sure OAuth supports our desired use case of passing
"protected" access tokens over plain http, based on my reading of section 10.3:
"Access token (as well as any access token type-specific at
Why not just ask for one access token with all the scopes you need, then
refresh it by asking for the different subsets you want.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Dan Taflin
> Sent: Tuesday, October 25, 2011 3:37 PM
>
14 matches
Mail list logo
