> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Brian Eaton
> Sent: Saturday, July 10, 2010 11:56 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] What to do about 'realm'
>
> On Sun, Jun 27, 2010 at
On Sun, Jul 11, 2010 at 8:19 PM, Eran Hammer-Lahav wrote:
> My bad. I forgot to update the ABNF for the parameters.
>
> credentials = "OAuth" RWS access-token RWS [ 1#auth-param ]
Thanks. I suppose it should be
credentials= "OAuth" RWS access-token [ RWS 1#auth-param ]
which I'll add t
I think "access credential" is better that either of those. Using
"grant" as a noun is a somewhat obscure usage, a la "land grant", which
I think of more as the deed to a property.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Eran Ha
I basically took all the characters allowed in headers and removed white-space
characters since they are used as separators. That's it. In other words, this
is what HTTP requires for sending tokens in headers (which is the most
consensus I was able to conclude from the list discussions). If peop
Eran,
Is then any reason to pick this collection of ASCII characters?
An access token appears in JSON, URI fragments, URI query parameters, and HTTP
header values. The allowed set includes chars that need escaping in all of
these. However, it is still a very limited set of 94 chars. It excludes
On 7/11/10 3:32 PM, "Robert Sayre" wrote:
> On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav
> wrote:
>> [this has noting to do with realm]
>>
>> Any solution should be:
>>
>> - Extensible we removed the few discovery parameters from the core spec
>> due to lack of maturity and consens
My bad. I forgot to update the ABNF for the parameters.
The right answer is 2 in the example below and the correct ABNF is:
credentials= "OAuth" RWS access-token RWS [ 1#auth-param ]
access-token = 1*( quoted-char / <"> )
quoted-char= "!" / "#" / "$" / "%" / "&" / "'" / "("
According to section 5.1.1, commas, equal signs, and quotation marks
are all allowed in the access-token. How do I parse the following
Authorization header?
Authorization: OAuth vF9dft4qmT,foo="bar"
1. The access-token is 'vF9dft4qmT', and the value of some extension
parameter 'foo' is 'bar'.
2.
Please use this link to post purely editorial feedback:
http://r9.sharedcopy.com/6djt2n9v
EHL
On 7/11/10 2:35 PM, "Eran Hammer-Lahav" wrote:
Draft -10 submitted. It includes the following changes:
o Fixed typos. Many editorial changes. Rewrote introduction. removed
terminology groupin
On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav wrote:
> [this has noting to do with realm]
>
> Any solution should be:
>
> - Extensible – we removed the few discovery parameters from the core spec
> due to lack of maturity and consensus. However, we clearly have enough
> strong interest in re
On Sun, Jul 11, 2010 at 1:22 PM, Eran Hammer-Lahav wrote:
> This is a naïve questions:
>
> Why not just say the server MUST match the redirection URI if one was
> previously registered, and require registration for user-agent clients?
I don't know enough to be sure that's the right answer. As fa
Draft -10 submitted. It includes the following changes:
o Fixed typos. Many editorial changes. Rewrote introduction. removed
terminology grouping.
o Allowed POST for end-user authorization endpoint.
o Fixed token endpoint to not require client authentication.
o Made URI query an
On Sun, Jul 11, 2010 at 1:03 PM, Eran Hammer-Lahav wrote:
> +1 with the exception of a new scheme name for signatures. I think we need
> to get to a stable draft before we can figure it out.
Very reasonable.
> But I would like to
> keep the core spec open for (small) changes until we do.
>
> I a
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 Protocol
Author(s) : E. Hammer-Lahav, et al.
Filename: dr
This is a naïve questions:
Why not just say the server MUST match the redirection URI if one was
previously registered, and require registration for user-agent clients?
EHL
On 7/10/10 11:44 PM, "Brian Eaton" wrote:
Section 3 says [[ provide guidance on how to perform matching ]].
I can writ
+1 with the exception of a new scheme name for signatures. I think we need to
get to a stable draft before we can figure it out. But I would like to keep the
core spec open for (small) changes until we do.
I added this to -10:
Authorization: OAuth [optional extension key="value" pairs]
EHL
[this has noting to do with realm]
Any solution should be:
- Extensible - we removed the few discovery parameters from the core spec due
to lack of maturity and consensus. However, we clearly have enough strong
interest in reintroducing them as extensions. The WWW-Authenticate header is
the na
There are valid arguments for a SHOULD NOT issue a refresh token. I'll make
the necessary changes.
EHL
On 7/10/10 8:09 PM, "Brian Eaton" wrote:
Hey folks -
The client credentials flow should never return a refresh token, for
the following reasons:
- it's never necessary
- it's a security p
The following was submitted via the shared-copy page but does not belong with
editorial feedback. This needs to be discussed and supported on the list before
added the specification. I think it belongs where 'immediate' is specified.
EHL
-- Forwarded Message
From: An anonymous reader
Date:
On 7/8/10 11:37 PM, "Brian Eaton" wrote:
> 1.4.4 Autonomous
>
> I think we need a better definition of Autonomous Clients, but I'm
> damned if I can think of one right now.
>
> "The scope of the access
> token is limited to the protected resources under the control of
> the clien
stpe...@stpeter.im wrote:
>
> And don't forget about several other sessions that might be of interest on
> Monday and Tuesday:
There's also HyBi aka WebSockets on Friday.
=JeffH
(who'll be in Maastricht)
___
OAuth mailing list
OAuth@ietf.org
https://w
This makes sense. I think this requires changing the 'basic client credentials'
to 'client password credentials'.
While not necessary, we might want to change 'client_secret' to
'client_password' to be more explicit and descriptive (since 'secret' can be
many things, but we are using it in an e
D.
On 8 Jul 2010, at 9:29 AM, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) Maybe, depends on some other reason
The spec organization isn't about reusing prose, but about providing a
consistent and well-defined protocol architecture. WRAP called the different
flows for each client 'profiles' which was wrong in WRAP because it wasn't
actually profiling anything - it was describing completely separate flows
+1. James states two important requirements (don't stand in the way of dynamic
config, provide end-user authz endpoint at a minimum) we need to meet, whatever
we pick.
Eve
On 11 Jul 2010, at 6:12 AM, Manger, James H wrote:
> Brian,
>
>> Or even just:
>>
>> WWW-Authenticate: OAuth2
>>
The problem with the original 'type' parameter and the flows in general is that
they tried to address a specific use case and then got expanded (or overloaded)
with other use cases. The user-agent and web-server flows became the foundation
of native applications, and there were people discussing
Brian,
> Or even just:
>
> WWW-Authenticate: OAuth2
>
> Seriously.
I seriously hope not.
It gives no chance for a client to work with a service without being
pre-configured with a whole lot of service-specific knowledge -- in addition to
an app-id/password.
I don't think a realm parameter adds
You mean the syntax used by most HTTP headers? There is clearly a need for
adding extensions.
EHL
On Jul 11, 2010, at 2:55, Brian Eaton wrote:
> On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav
> wrote:
>> 1. Leave it as required under the definition of RFC 2617 (i.e. provide no
>> help, d
According to this logic, everyone should be called a credential - access token,
refresh token, authorization code, etc.
Having too many similar terms is confusing and a mistake I refuse to repeat.
As for the so called bugs, so far most of your feedback is non-normative or has
little implement
On Sat, Jul 10, 2010 at 11:55 PM, Brian Eaton wrote:
>
> Let's use a format like this:
>
> WWW-Authenticate: OAuth2 base64()
>
> Or even just:
>
> WWW-Authenticate: OAuth2
>
> Seriously.
Looks good. Doesn't matter which the WG picks.
> 1) dropping the name="value" syntax won't break the internet
30 matches
Mail list logo
