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 ne
In the text on the authorization and token endpoints an assumption is made that
the query component of the URLs will be specified based on
x-www-form-urlencoded. But in fact that is never explicitly stated. What is
explicitly stated is that RFC 3986 section 3 has to be used (and then only for
t
Thanks to everyone who submitted WGLC comments on draft –20.
The majority of comments look good and will be applied to the specification as
they are purely editorial. A few are normative but some with significant
changes - I will open issues for those.
I plan to publish –21 next week.
EHL
___
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 new one is invented every other week.
The problem wi
I'll take a swag and your comment on #5. Based on the current abstract of the
OAuth 2.0 spec
The OAuth 2.0 authorization protocol enables a third-party application to
obtain limited access to an HTTP service, either on behalf of a resource owner
by orchestrating an approval interaction between
I'll take a swag and your comment on #5. Based on the current abstract of the
OAuth 2.0 spec
The OAuth 2.0 authorization protocol enables a third-party application to
obtain limited access to an HTTP service, either on behalf of a resource owner
by orchestrating an approval interaction between
The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based
on a thread about this from last year I was under the impression that it
was going to be relaxed to a SHOULD with most likely TLS 1.0 (or
posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require
1.2 when many sy
2: MAC Key: "The server MUST NOT reissue a previously issued MAC key and
MAC key identifier combination."
3: I would still like to see a binding for post body and url parameters.
This could be as simple as defining a set of parameter names for
everything used in the auth header, but I'm still giv
1.3: This draft still uses the term "access grant" where the core now
uses "authorization grant". Change all references to "authorization
grant" and reference section 1.4 in core. Also, too many parenthetical
statements in opening paragraph -- suggested rewrite of this bit:
Before a client
Precisely! In fact the anonymity of this sort can be achieved even
without a refresh token: as long as the end user is not required to
authenticate to the client.
But for all I remember, we have never had a SINGLE USE CASE (sorry to
transition to my pet peeve) that required anonymity. The or
> Please find below the text Niv and I prepared. In comparison to Niv's
> original proposal, it covers resource owner impersonation for all client
> categories.
This makes sense to me, and I like the proposed text.
Barry, as participant
___
OAuth maili
In some sense, but it is an indirect consequence of the fact the protocol is
for granting access
without requiring the revealing of user credentials, which in most (but not
all) cases means
hiding the user's identity on the system.
In many cases however, their identity is simply translated/embodie
Many APIs in practice have a method such as "/me" or "/profile" for
applications to retrieve the profile information of the resource owner given
their access token. IMO this is a completely appropriate use of OAuth, even
though the resource owner is no longer anonymous in this case. I agree that
it
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 st
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 fin
15 matches
Mail list logo
