On 2010-07-15, at 6:45 PM, Naitik Shah wrote:
> On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz wrote:
>
> One question: What's the deal with having the signature go first? If you can
> explain to me why that is a good idea, I'm happy to oblige.
>
>
> When we were talking about base64url or no
>> What happens if a 1.0 client receives a WWW-Authenticate header
>> from a 2.0 protected resource with the 'OAuth' mechanism specified?
>> Might it then attempt OAuth 1 with a 2.0 token service (and thus
>> just fail without being able to know what went wrong)?
> There is no such thing. Since th
On 2010-07-15, at 5:29 PM, Dirk Balfanz wrote:
> Hi Dick,
>
> you're right - after actually reading the paper :-), I agree that if you have
> both sender and receiver in your payload, the order (of encrypting and
> signing) doesn't seem to matter.
>
> I'm still hesitant, though, to optimize
On Thu, Jul 15, 2010 at 5:36 PM, Brian Eaton wrote:
> There are certain practical limits, but I think there is still blood
> on the specification from the last time normative language was
> discussed.
That must have been been before my time - sorry for bringing it up
again. We can put those skel
On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz wrote:
>
> One question: What's the deal with having the signature go first? If you
> can explain to me why that is a good idea, I'm happy to oblige.
>
>
When we were talking about base64url or not, putting the signature before
the dot meant it was ok
Hi guys,
after reading through the feedback, we did a pass over the OAuth signature
proposals.
As a reminder, there are three documents:
- a document (called "JSON Tokens") that just explains how to sign something
and verify the signature:
http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx
On Thu, Jul 15, 2010 at 6:35 AM, Eran Hammer-Lahav wrote:
> Access tokens should not be stored in plain text either since stealing
> them is just like stealing a password.
>
Access tokens are designed to be stored in plain text in less secure
environments - web browser cookie JAR, in RAM in inst
Hi Dick,
you're right - after actually reading the paper :-), I agree that if you
have both sender and receiver in your payload, the order (of encrypting and
signing) doesn't seem to matter.
I'm still hesitant, though, to optimize for the encryption use case now
(even though I do believe it will
As I see, the current draft is half way towards the complete modularization. It
has abstracted what parameters are needed for each end points from various
flows but failed to stop there and included how they are to be passed as well.
IMHO, how they are passed is the profile/binding issue and all
Sure, but it's not easy to early branch, you have to actually parse the
whole header. It's also fragile if extensions are not careful.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Naitik Shah
Sent: Thursday, July 15,
The formats for 1.0 and 2.0 are sufficiently different that it is possible
to unambiguously figure out what version is being used.
-Naitik
On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> where is the relation between token version and HTTP authenticatio
On Thu, Jul 15, 2010 at 4:04 PM, Brian Campbell
wrote:
> I'm guessing you don't want any language restricting the length of the
> code? Though there is some practical limit due to the URL length in
> the 302 (I think it has to be a redirect).
There are certain practical limits, but I think there
Am 15.07.2010 16:27, schrieb Christian Stübner:
Torsten,
I came across your I-D when looking for a way to distinguish between
different protected resources.
Just some remarks and questions:
o In 3.1. I suppose your example request is missing the service_id, right?
Yepp.
o 3.4. Replace s
No normative language needed. Security consideration is the right approach.
EHL
On Jul 15, 2010, at 19:05, "Brian Campbell" wrote:
> Okay, I'm with you. Some text guiding the more obvious (to me anyway)
> usage might still be useful. Something like,
>
> "If Authorization Code value is a
Okay, I'm with you. Some text guiding the more obvious (to me anyway)
usage might still be useful. Something like,
"If Authorization Code value is a reference to state on the server,
the value MUST/SHOULD be constructed from a cryptographically strong
random or pseudo-random number sequence [RF
where is the relation between token version and HTTP authentication
scheme version?
regards,
Torsten.
Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'd come to a decision on the versioning too :) IMHO, it's
better to push this burden of versioning into the token itself if
necessary. I t
Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Other
Even better, thanks!
On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wrote:
> On Thu, Jul 15, 2010 at 2:11 PM, David Recordon
> wrote:
> > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
> >> “The client makes the following request at an arbitrary but reasonable
> >> interval which
I though we'd come to a decision on the versioning too :) IMHO, it's better
to push this burden of versioning into the token itself if necessary. I
think it's better from a developers perspective to pass an oauth_token,
because it's cleaner. Most deployments will already have versioned tokens to
en
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
>> “The client makes the following request at an arbitrary but reasonable
>> interval which MUST NOT exceed the minimum interval rate provided by
>> the authorization server (if p
On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell
wrote:
> I must admit to never having considered the authz code as anything but
> a random string as a reference that must be resolved. Can you expand
> on your thinking a bit, if only to enlighten me?
>
> Are you thinking of embedding what would be
As written it probably does preclude that but I'm sure we could
massage it to be more flexible while still keeping the intent that the
code isn't something that can be easily guessed or is likely to
collide.
I must admit to never having considered the authz code as anything but
a random string as
On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary) <
zachary.zelt...@alcatel-lucent.com> wrote:
> Section 1.5:
>
> “The client makes the following request at an arbitrary but reasonable
>
> interval which MUST NOT exceed the minimum interval rate provided by
>
> the authorization serve
I'm gong to join the growing list of people attaching a potential I-D
to an email due to he cut off time for the I-D submissions. Attached
is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type. I'v
Section 1.5:
"The client makes the following request at an arbitrary but reasonable
interval which MUST NOT exceed the minimum interval rate provided by
the authorization server (if present via the "interval" parameter)."
My understanding is that the intervals between the client's subsequent r
On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher wrote:
> Looks good.
>
> Are there any restrictions on the device_code such that it has to be under
> a certain size? Seems like it would be good to protect against random
> polling attacks (I presume this is what the Google research refers to). I
Looks good.
Are there any restrictions on the device_code such that it has to be
under a certain size? Seems like it would be good to protect against
random polling attacks (I presume this is what the Google research
refers to). If there are no size restrictions then the device_code could
be
I've broken the device profile out of draft 06 so that it now lives in a
separate document as an extension and have updated it to fit into the draft
10 structure. It defines a new "device endpoint" for the initial setup
request where the client gets the two codes and URL. It then uses the
existing
> Framing the argument against "having a 2 in it" as bikeshedding is missing
> the point. My reason against using OAuth2 is that is will undermine all the
> work put in to build an extensible framework that can evolve without needing
> a whole new version. By putting a version number, we make it
> > It was discussed before, but I don't remember there being any consensus
> > in the group. What are the practical reasons for not using "oauth2"
> > namespacing in the one place we still use namespacing? Most of what I've
> > heard seems to sound like "I don't like it to have a 2 on it".
>
> I
On Thu, Jul 15, 2010 at 11:36 AM, Eran Hammer-Lahav wrote:
> Framing the argument against "having a 2 in it" as bikeshedding is missing
> the point. My reason against using OAuth2 is that is will undermine all the
> work put in to build an extensible framework that can evolve without needing
>
Lots of things can be done. Checking presence of oauth_signature_method
implies that the format is the same in all cases including the auth
header right?
What you seem to be arguing for right now is parsing the entire line to
decide which auth you do. I would *much* prefer a leading tag or schem
There is no such thing. Since there is no discovery for 1.0, all calls are
hardcoded into the client today. There is no 'trying things out'.
EHL
On Jul 15, 2010, at 14:33, "John Kemp" wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
>> I would like people to raise their han
On Jul 15, 2010, at 2:35 PM, David Recordon wrote:
> Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0
> client know about a 2.0 protected resource in the first place?
It wouldn't know anything other than it got back a WWW-Authenticate header when
accessing the resource
Framing the argument against "having a 2 in it" as bikeshedding is missing the
point. My reason against using OAuth2 is that is will undermine all the work
put in to build an extensible framework that can evolve without needing a whole
new version. By putting a version number, we make it more at
Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0
client know about a 2.0 protected resource in the first place?
On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
> > I would like people to raise their hand and
On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
> I would like people to raise their hand and explain how this will break
> actual 1.0 deployments.
What happens if a 1.0 client receives a WWW-Authenticate header from a 2.0
protected resource with the 'OAuth' mechanism specified? Might it
On Jul 15, 2010, at 10:51 AM, Justin Richer wrote:
> It was discussed before, but I don't remember there being any consensus
> in the group. What are the practical reasons for not using "oauth2"
> namespacing in the one place we still use namespacing? Most of what I've
> heard seems to sound like
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
wrote:
> As I have written in my reply to Marius's posting. I'm fine with including
> server ids in scopes. But this requires a definition of the scope's syntax
> and semantics in the spec. Otherwise, scope interpretation (and server
> identifi
It was discussed before, but I don't remember there being any consensus
in the group. What are the practical reasons for not using "oauth2"
namespacing in the one place we still use namespacing? Most of what I've
heard seems to sound like "I don't like it to have a 2 on it".
I don't want to have
No, the people who don't like the sharing of the namespace between the 2
still don't like it, and the people that can;t stand teh idea of using
oauth2 for anything still won't move.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of
On Thu, Jul 15, 2010 at 10:37 AM, David Recordon wrote:
> I thought this topic had been beaten to death before.
Can you give me a pointer to the earlier threads?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Thu, Jul 15, 2010 at 7:22 AM, Brian Campbell
wrote:
> The Authorization Code value MUST be constructed from
> a cryptographically strong random or pseudo-random number
> sequence [RFC1750] generated by the Authorization Server.
> The probability of any two Authorization Code values
I thought this topic had been beaten to death before. An OAuth 1.0 protected
resource request includes a variety of oauth_ parameters whereas OAuth 2.0
just has oauth_token.
--David
On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton wrote:
> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote:
>
+1 for both
2010/7/15 Justin Richer :
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
>
> 1.0 clients will talk to systems that support both oauth2 and oauth1
> simultaneously. Most likely on the same PR endpoints as well. Since the
> protocols are n
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> As I have written in my reply to Marius's posting. I'm fine with including
> server ids in scopes. But this requires a definition of the scope's syntax
> and semantics in the spec. Otherwise, scope interpret
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
Good point about the query parameter names needing to be unambiguous.
___
OAuth mailing list
OAuth@ietf
sounds really good.
+1 for adding this to the authorization code's specification.
Am 15.07.2010 16:22, schrieb Brian Campbell:
I agree it's important but it belong in security considerations or
perhaps somewhere in the definition of the Authorization Code itself?
Either way here's some text th
As I have written in my reply to Marius's posting. I'm fine with
including server ids in scopes. But this requires a definition of the
scope's syntax and semantics in the spec. Otherwise, scope
interpretation (and server identification) will be deployment specific.
In your example, ':' is used
Well, no. We're rolling out new Oauth 1.0a stuf even now, because 2.0
isn't ready and Oauth 1.0a is better than many alternatives.
>
> OAuth is dead, long live OAuth. Right? I mean, you don't move
> the White House to another address every time you get a new
> president...
>
> b.
On 15 July 2010 15:59, Justin Richer wrote:
> +1 on OAuth2 header, and I also want to see oauth2_token in URI and form
> parameter methods.
>
> 1.0 clients will talk to systems that support both oauth2 and oauth1
> simultaneously. Most likely on the same PR endpoints as well. Since the
> protocols
+1 on OAuth2 header, and I also want to see oauth2_token in URI and form
parameter methods.
1.0 clients will talk to systems that support both oauth2 and oauth1
simultaneously. Most likely on the same PR endpoints as well. Since the
protocols are not backwards compatible, they should be able to co
My post was a reply to
http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html.
(Something obviously went wrong with the Thread Index.)
Regards,
Christian
> Torsten,
>
> I came across your I-D when looking for a way to distinguish between
> different protected resources.
>
> Just so
Torsten,
I came across your I-D when looking for a way to distinguish between
different protected resources.
Just some remarks and questions:
o In 3.1. I suppose your example request is missing the service_id, right?
o 3.4. Replace server_id by service_id and you comply with the rest of the
docu
I agree it's important but it belong in security considerations or
perhaps somewhere in the definition of the Authorization Code itself?
Either way here's some text that could be used as a starting point. I
borrowed heavily from concepts and language in SAML regarding
artifacts and IDs which bear
Hi @all!
Here is my feedback to the current version (-10) of the draft. So far it
looks really promising to me.
Just a view thoughts/ideas/questions:
1.4: Is it necessary for an authorization server to support all client
profiles in order to be standard complaint?
1.4.1. Wording: Profile "Web S
You need to verify that when you use an authorization code, not when you use an
assertion.
EHL
On 7/15/10 3:54 AM, "Elena Lozano" wrote:
Hi everyone,
As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the draft
we have found some issues regarding the client secret and clie
Access tokens should not be stored in plain text either since stealing them is
just like stealing a password.
As for cookies, client developers do very little to protect cookies today.
While the theory might be similar, in practice, telling a client developer this
is just like a cookies doesn't
No. It is.
Let me ask you this: why can't you use 'photos:server1' and 'photos:server2' as
scopes?
EHL
On 7/14/10 10:49 PM, "Torsten Lodderstedt" wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments with
different resource servers which rely in a single authz serv
To elaborate a bit:
Since there is no discovery in 1.0, the only place this can create a conflict
is on the server side, when servers support both new and old schemes, and need
to tell which version the client is using. This is the same issue as using the
'oauth_token' parameter in the query or
I would like people to raise their hand and explain how this will break actual
1.0 deployments.
EHL
On Jul 15, 2010, at 1:38, Brian Eaton wrote:
> Draft 10 switched from "Token" scheme in the authorization header to
> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
> "
Why don't you use the client secret to authenticate the application? The spec
allows you to use a BASIC authorization header for that purpose.
Regards,
Torsten.
Am 15.07.2010 um 12:54 schrieb Elena Lozano :
> Hi everyone,
>
> As we adapt the RedIRIS PHP OAuth2 library[1] to the last version o
Hi everyone,
As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the draft
we have found some issues regarding the client secret and client id.
The thing is that we don't understand the security given with the client_id and
client_secret of the assertion profile.
The last chan
An important point, which I think should be captured in the security
consideration section.
Igor
Torsten Lodderstedt wrote:
what about guessing/brute force attacks on the code? Supposed an
authorization server issuing tokens for a client w/o secret. Then the
number of attempts needed to obtai
> Draft 10 switched from "Token" scheme in the authorization header to
> "OAuth". I'd rather we didn't reuse OAuth.
I agree that "OAuth" is taken as a scheme name.
I like "Bearer" for the Authorization header scheme holding an access token.
We should use a different name for the WWW-Authenticati
65 matches
Mail list logo
