Yes, I think the kitten list is the right place:
https://www.ietf.org/mailman/listinfo/kitten
But it would be good for OAuth folks to review the spec and post their
comments on the kitten list (or directly to the authors).
/psa
On 2/16/11 5:28 PM, William Mills wrote:
> I'm happy (ecstatic, hop
I'm happy (ecstatic, hopeful, yearning) to take comments, although I guess the
etiquette is that it should happen on the Kitten WG mailing list?
-bill
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Peter Saint-Andre
> Sent: Wednesday
Just saw this come across the wire...
Original Message
Subject: I-D Action:draft-mills-kitten-sasl-oauth-01.txt
Date: Wed, 16 Feb 2011 14:45:01 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
A New Internet-Draft is available fro
Feel free to propose alternative preamble for the implicit and authorization
code sections, describing the characteristics of what they are good for. It
should fit in a single paragraph. Such a proposal would fit right in with last
call feedback to -13.
EHL
> -Original Message-
> From:
On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav wrote:
> The reason why we don't return a refresh token in the implicit grant is
> exactly because there is no client authentication...
Not sure that's the main reason. AFAIK it is because the response is
sent through the user-agent and it coul
The reason why we don't return a refresh token in the implicit grant is exactly
because there is no client authentication... These are all well-balanced flows
with specific security properties. If you need something else, even if it is
just a tweak, it must be considered a different flow. That d
The implicit grant still requires a redirect of some kind, so many
native apps can just as easily use the web server flow as the implicit
flow. I personally don't see how the implicit flow is better suited than
the web flow in this case. However, neither of these are ideally suited
for native a
Exactly Marius, and in most cases the app will want to procure a
refresh token as a result of the dance so it won't have to put the
user though the authorization process again and again. Unless I'm
mistaken, the implicit grant provides no means of obtaining a refresh
token (http://tools.ietf.org/h
On Wed, Feb 16, 2011 at 11:06 AM, William Mills wrote:
> Token endpoint with username/password credential doesn't solve this? Depends
> on the auth scheme of course, but Bearer should provide a solution?
Not at all, in most case native apps must use the browser based 3-legged dance.
Marius
___
Token endpoint with username/password credential doesn't solve this? Depends
on the auth scheme of course, but Bearer should provide a solution?
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Wednesday, February
Unless someone provides a proposed text to address internationalization
consideration for username and password, I am going to remove this note
unaddressed.
EHL
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Authorization Protocol
Author(s) : E. Hammer-Lahav, et al.
Filena
Yes.
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, February 16, 2011 10:58 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
>
> On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav
> wrote:
>
Draft -13 includes all feedback received (unless was noted otherwise on the
list) to date. It does not include any implementation changes since -12. Given
the stable state of this draft and the lack of any blocking issues raised for
the included text, I would like to officially request the chair
On Wed, Feb 16, 2011 at 10:43 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Wednesday, February 16, 2011 9:05 AM
>
>> Yes, I understand. But Native Apps have no appropriate flow now, and they
>> started the whole pr
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, February 16, 2011 9:05 AM
> Yes, I understand. But Native Apps have no appropriate flow now, and they
> started the whole protocol.
I am not sure "they started the whole protocol" (it was mor
(a) is more appropriate. See -13 for revised language.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Stuebner, Christian (extern)
> Sent: Wednesday, February 16, 2011 8:01 AM
> To: 'oauth@ietf.org'
> Subject: [OAUTH-WG] Missing Clie
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Richer, Justin P.
> Sent: Thursday, January 27, 2011 12:05 PM
> 1.2
>
> "Tokens may be pure capabilities." To a non-security-engineer such as
> myself, this bit reads very oddly on its own
On Wed, Feb 16, 2011 at 9:00 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Wednesday, January 26, 2011 12:09 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
>>
>> -
> -Original Message-
> From: Skylar Woodward [mailto:sky...@kiva.org]
> Sent: Thursday, January 27, 2011 2:37 AM
> -- 3.1.1, 4.1.2, and Out-of-Band flows
>
> It is an important consideration for us that clients that cannot capture a
> redirect from the user-agent be able to use authenti
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, January 26, 2011 12:09 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
>
> - 4.1. Authorization Code. It is stated that authorization code is su
Re: 4.3. This could be something to put in security considerations. Since
there will be reasonable cases where for example a password hash is retained.
And as indicated by Eran, this is a best practice rather then an inter-op issue.
Phil
phil.h...@oracle.com
On 2011-02-16, at 8:34 AM, Eran
> -Original Message-
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Wednesday, January 26, 2011 12:09 PM
> - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that
> the client MUST discard the credentials once it obtains an access token. I
> think it SH
Hi all,
I noticed a minor change in wording for the error response codes at the token
endpoint (see citation below).
But I'm still not sure how an authorization server is expected to behave in
cases where he supports client password authentication via request parameters
and HTTP Basic authentic
24 matches
Mail list logo
