On 37-01--10 11:59 AM, Brian Campbell wrote:
Yeah, I had just sort of being going off the assumption that
client_id is required& client_secret is not but, looking at -15
again, I agree that it's not entirely obvious. There's the text at
the end of section 3 that say allows for unauthenticated
Hi Chuck,
one of the advantages of the authz code grant type is refresh token support. I
would suggest to mention this in the comparision with the implicit grant type.
regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Chuck Mortimore
All section 3 says is that you cannot use it alone for authentication. You can
use it alone, but it is not considered authentication and the client identity
is nothing more than a hint without other information you can validate.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] O
Hey guys I am working the engineers at my company to roll out OAuth 2
support for mobile and desktop.
One concern is Section 3 of the spec calling out the fact that client id
should not be used by itself, however the implicit grant does just that.
And the new native apps section does not provide p
One of my items from yesterday was to update the text related to native
applications. Primary goals were to:
1. remove the explicit preference for authorization_code grant type
2. provide a brief overview on means of initiating authorization requests and
receiving callbacks
3. discuss t
George, you are correct that resources and clients must agree upon the format
of the bearer token to achieve interoperability. The means for achieving this
agreement is out of the scope of this document.
-- Mike
-Original Message-
From: Marius Scurtescu
I think that this will be better moved into a separate document on assertions
(were both authorization and authentication are talked about) and not to
include in 4.5.1 but would like to see a reference in 4.5.1 to the new document
-Original Message-
From: oauth-boun...@ietf.org [mailto:o
The "printable non-whitespace ASCII characters" represents the access
token, which is supposed to be opaque. I don't think this affects
libraries.
Marius
On Tue, May 24, 2011 at 10:24 AM, George Fletcher wrote:
> Do I understand this correctly that each resource owner can define it's own
> for
On 5/24/11 11:31 AM, Brian Campbell wrote:
> I noticed yesterday, in -16, that the first time that client_id is
> mentioned is in a parenthetical in the second paragraph of section 3.1
> which is a little awkward. The client_id parameter then shows up
> inside two examples before being listed as a
I noticed yesterday, in -16, that the first time that client_id is
mentioned is in a parenthetical in the second paragraph of section 3.1
which is a little awkward. The client_id parameter then shows up
inside two examples before being listed as a required parameter in
section 4.1.1, 4.1.3, 4.2.1
Do I understand this correctly that each resource owner can define it's
own format for the "printable non-whitespace ASCII characters"? It seems
like that would make it difficult for clients to use standard libraries
because the Authorization header format could be different on a per
resource/h
One of the action items out of yesterday's meeting was to draft some
text for a section 4.5.1 in core that defined the optional but
recommended use of an "assertion" parameter for extension grants where
the use of a single parameter to carry the grant/assertion was
possible. Below is a first cut a
Hi all,
- 10 Security considerations
- 10.10 Session fixation...
Breno does not feel that session fixation is properly described nor
dealt with.
Breno is right. The threat that shall be prevented here is described
in the security threat document
(http://tools.ietf.org/html/d
13 matches
Mail list logo
