Hi Eran,
why do you see a relationship between dynamic client registration and
discovery? Basically, we don't care so far how a client finds tokens and
end-user authorization point. Why is this any different for the client
registration endpoint (or the revocation endpoint)? Or do you have a
Hi all,
is there enough experience in the field with such an interface to
standardize it?
I would expect such an endpoint to return the same payload, which is
carried in a JSON Web Token. So once we designed the JSON Web Tokens
content, designing the AS-PR interface could be the next
:
Because it is in the draft the WG is suppose to consider. It's a stated
dependency.
EH
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, April 18, 2012 12:50 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG
18.04.2012 22:01, schrieb Justin Richer:
Not all implementations in the field that do this are using JWTs as
the tokens. Ours in particular used a random blob with no structured
information in it. The endpoint returned a JSON object.
-- Justin
On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote:
Hi
Hi Grant,
did you consider to use the binary security token feature of WS-Security?
http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm#ws-security__toc6201554
We use it for some services.
regards,
Torsten.
Guang Yang guang.g.y...@oracle.com schrieb:
Thank you. Actually I am
Hi Barry,
we incorporated all issues we were aware of in the last revision (esp.
Tim Bray's review comments).
regards,
Torsten.
Am 14.03.2012 22:23, schrieb Barry Leiba:
Looks good to me. One note:
2. OAuth Threats Document (Torsten)
-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
In my opinion, dynamic client registration would allow us to drop
public client thus simplifying the core spec.
regards,
Torsten.
Am 15.03.2012 16:00, schrieb Eran Hammer:
I believe most do, except for the dynamic client registration. I
don't have
secrets.
While we did do dynamic client registration for
Connect that is a more constrained use case.
I would put JWT and
AS-RS communication as higher priorities than dynamic registration.
Partially because they are more self contained issues.
John B.
On 2012-03-21, at 4:35 PM, Torsten
Hi Paul,
for me, your proposal looks like the natural counterpart of JWT, as it
standardizes the way to implement handle-based token designs (in
contrast to self-contained tokens).
therefore +1 from my side.
regards,
Torsten.
Am 15.03.2012 11:35, schrieb Paul Madsen:
+1 to defining RS-AS
In my opinion, dynamic client registration would allow us to drop public
client thus simplifying the core spec.
regards,
Torsten.
Am 15.03.2012 16:00, schrieb Eran Hammer:
I believe most do, except for the dynamic client registration. I don't have strong
objections to it, but it is the least
Hi Hannes,
+1
You have compiled a list of meaningful and feasible objectives.
regards,
Torsten.
Am 14.03.2012 21:21, schrieb Hannes Tschofenig:
So, here is a proposal:
---
Web Authorization Protocol (oauth)
Description of Working Group
The Web Authorization (OAuth) protocol allows a
Hi,
Ross Boucher rbouc...@gmail.com schrieb:
The spec doesn't seem to have any recommendations on this point, but
should an OAuth v2 API always return the same access token if the same
client makes multiple requests? Is there any benefit to not generating
a new access token for each request?
Hi Tim,
I just submitted the revised version of the OAuth 2.0 security document
(http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This
revision should address the issues you raised in your AppsDir review. We
especially removed all normative language from the document.
We took
Hi Nat,
...
We probably should put some text that gives flexibility
in that respect, such as or put in place the controls that achieves
equivalent risk mitigation. etc.
One could add this text to nearly any of the guidelines given in Section
10. But how do you assess the equivalence of the
Hi,
thanks for the thoroughly review.
The threat document is intended to become an Informational RFC. So we
will follow your advice and remove all normative language.
regards,
Torsten.
Am 23.01.2012 22:47, schrieb S Moonesamy:
The following is the AppsDir review performed by Tim Bray. It
MUST sounds reasonable
Eran Hammer e...@hueniverse.com schrieb:
The current text:
If the issued access token scope
is different from the one requested by the client, the authorization
server SHOULD include the scope response parameter to inform the
client of the actual
Hi Paul,
that's not what I meant. The Client should know which tokens should be one time
usage based on the API description. The authz server must not return expires_in
because this would not make any sense in this case.
regards,
Torsten
Paul Madsen paul.mad...@gmail.com schrieb:
Hi
good point
William Mills wmi...@yahoo-inc.com schrieb:
One use tokens can also expire before they are used. You have 5 minutes to do
this once.
_
From: Torsten Lodderstedt [tors...@lodderstedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
makes sense.
regards,
Torsten.
Am 16.01.2012 20:00, schrieb Eran Hammer:
Added the word 'credentials' (e.g. Access token credentials (as well
as...) to make this clearer. IOW, when using MAC tokens, the token
secret is the part that must be protected, not the token id.
EHL
Hi,
an invalid token should cause the server to reply with status code 401.
regards,
Torsten.
Bart Wiegmans b...@all4students.nl schrieb:
Hi,
As far as I know, the implementation of API endpoints is outside of the
specification of OAuth.
But the specification of Bearer Tokens state that
Hi,
your observation is correct. OAuth security considerations recommend not to
rely on secrets for authenticating mobile apps (aka native apps) but to manage
them as so-called public clients. Please take a look onto section 10 of the
core spec for further details.
regards,
Torsten.
Karim
Hi Michael,
Am 04.01.2012 22:06, schrieb Michael Thomas:
I think the perhaps unwisely goes to the heart of my objection. You
might as well be talking about perhaps unwisely driving a car,
or perhaps unwisely eating food: the reality is that people download
apps by the *billions*. When I was
Hi,
Amos,
I believe that the draft addresses the replay matters by specifying
the validity time field. Do you see a problem with that?
I did not see any such validity time field in the HTTP mechanisms.
You mean the validity period of the token itself? that would be
irrelevant as the
Hi,
you are right, iframe is not the correct techniquehere. Browsers are
embedded into a native UI using browser widget or something similar. I
think ... embedding a browser into the application's user interface
when requesting end-user authorization ... would fit better.
regards,
Torsten.
in to the existing OAuth work
and libraries.
John B.
On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
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
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC a MUST for
clients and BEARER a MAY only. In my opinion, this does not reflect the
group's consensus. Beside this, the security threat analysis justifies
usage of BEARER for nearly all use cases as long as HTTPS (incl.
If we must define a mandatory token type then bearer + TLS would be my
suggestion.
regards,
Torsten.
Am 02.11.2011 21:28, schrieb Stephen Farrell:
Hi Torsten,
On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote:
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC
Hi Andre,
how do you think differs the threat you descibed from
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4?
regards,
Torsten.
Am 26.10.2011 22:44, schrieb André DeMarre:
Should a brief explanation of this be added to the Threat Model and
Security
will not possess the username and password
of they end user -- it might only possess a currently valid access
token. It would seem that including such a token should be a viable
authentication mechanism.
Craig McClanahan
On Fri, Sep 16, 2011
at 12:32 PM, Torsten Lodderstedt wrote:
Hi all
:56 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Hi all,
my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard
protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first
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
Author(s) : Torsten Lodderstedt
Mark McGloin
Phil Hunt
Filename: draft-ietf-oauth-v2-threatmodel-01.txt
Pages : 64
Date: 2011-10-26
This document gives security considerations
spec is voted on.
Regards
John B.
On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
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
. Thanks for the link.
I'm having trouble finding the current device flow proposal. The last
mention of it I remember was an earlier oauth-v2 draft. Can you send
me a current link?
Cheers,
Forest
On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Hi
Hi,
there is no contradiction. The subtle difference lays in the word instance.
Using secrets for a software package (and all of its installations) is useless
and therefore not allowed. If you are able to issue a distinct id/secret pair
to every installation of your app, this is fine.
For a
Hi all,
my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard protocol,
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is
missing from my point of view and explain some thoughts how to fill
the gaps.
A
to verify
the client's identity.
What am I missing?
Thanks,
Dave
On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Hi Dave,
redirect URI validation does not authenticate a client. For example,
a URI registered
I reviewed the diffs and it looks ok.
regards,
Torsten.
Am 07.09.2011 17:59, schrieb Barry Leiba:
As you've all probably seen, Eran has posted version 21 of the OAuth
base spec, in which he believes he's addressed all comments and issues
that came up in the review of version 20. We should be
-0700
Von:internet-dra...@ietf.org
An: tors...@lodderstedt.net
CC: sdro...@gmx.de, tors...@lodderstedt.net, mscurte...@google.com
A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been
successfully submitted by Torsten Lodderstedt and posted to the IETF repository
Hi Eran,
As far as I understood, in a textbook CSRF attack the attacker would
create
his own requests in order to abuse a user's session. This can be
prevented by
utilizing standard CSRF coutermeasures (page token, nounce,
signature as
parameter on every request URL), which bind URLs to a
Hi Dave,
On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:
1. The user does not have to be present.
Maybe I should be more clear. What benefit does that have over just a
long-lived (forever) access token? The cost is the extra complication
for
3rd party developers to have to worry
-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, September 14, 2011 6:51 AM
To: Eran Hammer-Lahav
Cc: Niv Steingarten; oauth@ietf.org
Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner
Impersonation)
Hi Eran,
As far as I understood, in a textbook CSRF
Hammer-Lahav
Sent: Sunday, August 14, 2011 11:09 PM
To: Torsten Lodderstedt
Cc: tors...@lodderstedt-online.de; oauth@ietf.org
Subject: Re: [OAUTH-WG] redirect uri validation
Where would you suggest I add this?
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors
Hi Eran,
This is still just a CSRF attack.
I think you may be right. I still believe this particular style of attack on the
authorization server is worth mentioning, be it in its own separate section or
under the existing CSRF section (as you suggested).
This is not a style of attack but
My intention is to require clients to implement CSRF prevention. I
thought making the state parameter mandatory would be the
straightforward way.
regards,
Torsten.
Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of the proposed change
about
I can see the logic of putting both token types first (though I still
prefer the auth grant first), but having the auth grant in between the
two token types is definitely a bad idea.
+1
-- Justin
___
OAuth mailing list
OAuth@ietf.org
Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to
better documenting it (though I feel the current text is already
sufficient), but we can't realistically expect to identify and close
every possible browser-based attack. A
Hi all,
I think the impersonation issue as raised by Niv on the list should be
covered by the core spec. It directly aims at the trustworthiness of the
user consent, which in my opinion is one of the core principles of
OAuth. I therefore suggest to add a description to section 10.
Please
OAuth allows a client to access user resources without revealing the
resource owner's identity to the client. Isn't this anonymity? I
consider this an important property of the protocol.
regards,
Torsten.
On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:
This seems to need a chair to
of token or nonce in
the submission of the form (which would still not prevent the attack
if the authorization server doesn't enforce same origin policy).
Niv
On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Hi Niv,
thank you for posting this to the list. I think you
it more esthetically pleasing (the server doesn't mind having an empty
parameter included, just people), but that's as far am I'm (as wg
member) willing to support, especially at this point.
EHL
From: Torsten Lodderstedt tors...@lodderstedt.net
mailto:tors...@lodderstedt.net
Date: Wed, 27
+1
Am 28.07.2011 15:10, schrieb Brian Campbell:
I would be very much in favor of that addition/clarification.
On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.com wrote:
[...] and I can also add a short note that public clients may use
the client_id for the purpose of
Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
The way I've set it up in --18 is that the client_id parameter in the
authorization endpoint is used to identify the client registration
record. The identifier is described in section 2.3. Then in section
2.4.1 the parameter is extended for use
, schrieb Eran Hammer-Lahav:
You just issue them a set of password credentials (which can include
an empty or fixed password). There is nothing preventing you from
doing that and once you do, the spec requires them to use those
credentials.
EHL
From: Torsten Lodderstedt tors...@lodderstedt.net
I personally think that would be more confusing than just adding the
client_id parameter to the token endpoint request (independent of client
authentication credentials).
Am 27.07.2011 18:17, schrieb Brian Campbell:
I think that would be helpful, thanks.
On Wed, Jul 27, 2011 at 12:43 PM,
Hi Eran,
section 5.2
The authorization server MAY return an HTTP 401
(Unauthorized) status code to indicate which HTTP
authentication schemes are supported.
Given the usage of HTTP authentication schemes is the way to authenticated
client recommended by the
Hi Eran,
Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Wednesday, July 20, 2011 2:15 PM
The authorization server redirects the user-agent to the
client's
(e.g. refresh tokens) issued to such clients.
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Sunday, July 10, 2011 1:59 AM
*To:* Eran Hammer-Lahav; OAuth WG
*Subject:* RE: Section 10.1 (Client authentication)
Hi,
I just remembered the original aim of the text. We not just
Hi Eran,
Regarding this particular section: I think the two different issues (transport
security and endpoint authenticity) should be presented separately.
Which section?
3.1.2.1.
regards,
Torsten.
EHL
___
OAuth mailing list
OAuth@ietf.org
Hi Eran,
OAuth 1.0 was highly criticized for failing to address client identity
in public clients. I believe OAuth 2.0 offers a much better story,
within the boundariesof what’s possible today.
Agreed. I think we must honestly discuss the value of client
authentication/identification itself. I
Hi Niv,
thank you for posting this to the list. I think you are right with your
threat description. One question: shouldn't the browser already prevent
the request to the authorization endpoint because of the same origin
policy (or CORS restrictions)?
Apart from that, a similar attack can
So far response type values are just strings one need to compare
literally. What use case justifies the more complex proposal?
regards,
Torsten.
Am 15.07.2011 19:44, schrieb Eran Hammer-Lahav:
I was only arguing against the proposed text which doesn't accomplish
what you want from a
2.1 Client types
I'm struggeling with the new terminology of private and public
clients. In my perception, the text just distinguishes clients which can
be authenticated and such which cannot. This is fine but I consider the
wording misleading. I would suggest to change it to something like
not SHOULD?
regards,
Torsten.
Am 20.07.2011 22:56, schrieb Torsten Lodderstedt:
2.1 Client types
I'm struggeling with the new terminology of private and public
clients. In my perception, the text just distinguishes clients which
can be authenticated and such which cannot. This is fine but I
The authorization server redirects the user-agent to the
client's redirection URI previously established with the
authorization server during the client registration process.
Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via
URI query parameter.
3.1.2.1 Endpoint
just a minor issue
In addition,
this specification does not provide a mechanism for refresh token
rotation.
The spec provides a mechanisms. It allows for the issuance of a new
refresh token with every request to referesh an access token.
regards,
Torsten.
section 1.5
(A) The client requests an access token by authenticating with the
authorization server, and presenting an authorization grant.
This statement does not reflect that client authentication is not always
required.
Proposal:
The client requests an access token by presenting
Why?
William J. Mills wmi...@yahoo-inc.com schrieb:
I agree that this is something you could do, but it doesn't seem like a good
design pattern.
_
From: Torsten Lodderstedt tors...@lodderstedt.net
To: Eran Hammer-Lahav e...@hueniverse.com; OAuth
replacement of the refresh token with every access token refresh is an example.
The authz server creates and returns a new refresh token value with every
access token refreshment. The old value is invalidated and must not be used any
further. Note: The authz server keeps track of all old
in the
document.
Can you list exactly what you have in mind by 'other means'? Just the bullet
points will be enough.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, July 08, 2011 12:59 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Section 10.1
without making breaking changes.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Friday, July 08, 2011 1:23 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: [OAUTH-WG] state parameter and XSRF detection
Hi Eran,
including dynamic values within redirect uris is standard
.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 06, 2011 12:48 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: Section 10.1 (Client authentication)
Hi Eran,
I would suggest to change it to SHOULD and add a reference to
https://tools.ietf.org/html/draft-ietf
Of Torsten Lodderstedt
Sent: Monday, June 27, 2011 2:22 PM
To: OAuth WG
Subject: [OAUTH-WG] state parameter and XSRF detection
Hi all,
while working on a new revision of the OAuth security document, a question
arose I would like to clarify on the list.
The state parameter is supposed
Hi Brian,
your text is definitely a valuable contribution. Please note: your earlier text
on OAuth security considerations has already been incorporated into the
security document.
I would suggest to first incorporate your new text there (probably together
with your proposal regarding
are. It will only be
understood by security experts and they don't really need it. At a minimum, it
needs some examples.
EHL
From: Torsten Lodderstedt tors...@lodderstedt.net
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav e...@hueniverse.com, OAuth WG oauth@ietf.org
Subject: Section 10.1
Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav:
This debate has been going on for 3 years. In OAuth 1.0 it was called
token attributes. Someone just need to write a proposal. Last time I
tried, no one wanted to implement any such mechanism.
we already did
regards,
Torsten.
EHL
Hi all,
I just posted the new revision of the OAuth 2.0 security threat model
and considerations document as WG item
(http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00).
We incoporated all feedback we got on the list and at IETF-80. Many
thanks to all people who have given us
Hi all,
I would like to announce that we recently launched OAuth 2.0 support in
our Security Token Service. It will be used in upcoming consumer
products (e.g. Smartphone apps).
The current implementation supports draft 10 (but is also inline with
the latest text on native apps). It has the
Hi all,
while working on a new revision of the OAuth security document, a
question arose I would like to clarify on the list.
The state parameter is supposed to be used to link a certain
authorization request and response. Therefore, the client stores a value
in this parameter that is
What seems to be missing in the discussion and the security considerations
of the spec is a decent list of general and grant-type-specific security
implications/pros/cons for the system if meaningful client authentication
at the token endpoint is available or not available.
What about this?
-1 making client authentication required at the access token endpoint
Client authentication is useful in some situations to raise the security
level. But requiring it will either keep out native apps or force there
developers to use useless/insecure secrets (I would call this pseudo
token_type is defined in the core spec only and indicates the token type
to the client and not the resource server.
So either the core spec defines a way to distinguish token types towards
resource servers (probably by utilizing the token_type parameter) or the
respective schemes (BEARER,
Certainly not. Are we discussing to make client authentication required
just for syntactical purposes?
To me, notasecret logically means to abandon on client authentication.
regards,
Torsten.
Am 16.06.2011 21:46, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
tors
Am 16.06.2011 22:02, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Certainly not. Are we discussing to make client authentication
required just for syntactical purposes?
That is what I'd like
no I'm saying people will use real secrets and rely on them - just as
with OAuth 1.0
Am 16.06.2011 22:20, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
No, it's not simpler nor clearer
Am 16.06.2011 22:30, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
no I'm saying people will use real secrets and rely on them - just
as with OAuth 1.0
=)
People are going to ignore what
in a server under control of the service provider and not
accessible to the end-user.
regards,
Torsten.
Thanks.
/thomas/
_
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Thursday
Hi,
I also see the need to request and issue multiple tokens in a single
authorization process. There has already been some discussion about this
topic roughly a year ago:
- http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html.
-
+1
Skylar Woodward sky...@kiva.org schrieb:
This may be true for a secret of sorts in some applications, but not for the
client_credential in OAuth. The client secret is the only element that can
secure the identity of the app and if it is compromised then so is the ability
of the app to
I fully agree with Brian and would like to add some thoughts:
Not authenticating the client does not directly create a security
problem at all. If we would follow this line, every e-Mail client out
there would be considered insecure because the client itself is never
authenticated. Not even
/
__
-Original Message-
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards
I'm getting confused. This thread is about native apps. So why discuss
security considerations for web apps here?
regards,
Torsten.
Am 01.06.2011 09:00, schrieb Brian Eaton:
On Tue, May 31, 2011 at 11:47 PM, Kris Seldenkris.sel...@gmail.com wrote:
If a provider chooses to do that though, in
Am 01.06.2011 08:56, schrieb Brian Eaton:
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
cmortim...@salesforce.com wrote:
It’s not entirely necessary; I’m just having a tough time figuring out any
practical difference between the implicit grant flow, and the webserver flow
with no
Hi Eran,
would you please add the following sentence (which was contained in the
original security considerations text) to the second paragraph of
section 1.0.1?
Alternatively, authorization servers MUST utilize
other means than client authentication to achieve their security
Hi Mark,
Am 31.05.2011 22:58, schrieb Mark Mcgloin:
Eran
Here are some additional sections to add to the next draft under security
considerations
CSRF
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
I think refresh token support in implicit grant is worth a discussion.
The main difference to authz code from a security perspective is that
the refresh token as long term credential could be disclosed via the
user agent's URL history. In my perception, this fact and the assumption
that user
the security considerations section does recommend to not automatically
process repeated authorizations without validating the client's identity
The authorization server SHOULD NOT automatically, without active
end-user interaction, process repeated authorization requests without
Am 28.05.2011 20:25, schrieb Doug Tangren:
I just re-read draft 16 on this memorial day weekend :)
1. I had a comment on the suggested use of the authorization code flow
for native clients [1].
Section 10.9 on auth code transmission [2] suggests users of the auth
code flow should
why must the redirect_uri be validated if it is pre-registered and not
included in the authorization request?
regards,
Torsten.
Am 29.05.2011 18:20, schrieb Eran Hammer-Lahav:
This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is
must match the location actually used by the
for the pass a
redirect uri with every authz request.
Is OAuth supposed to support (2)?
regards,
Torsten.
Doug Tangren d.tang...@gmail.com schrieb:
-Doug Tangren
http://lessis.me
On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt tors...@lodderstedt.net
wrote:
why must the redirect_uri
601 - 700 of 975 matches
Mail list logo
