why that? If there will be a signature proposal for resource server
access, the same (simplified?) model could be applied to the authz
server's API.
And as I pointed out in my original posting, I see this as a _further_
option not the only one. While it is technically more complicated, it
has
Password doesn't seem to be the right analogy. You don't (or really
shouldn't) store passwords in plain text or in cookies.
How about cookies? Most web developers understand that cookies are used as
a token that grants access to resources. We've also called these tokensAPI
cookies when trying to
I haven't seen the proposed discovery stuff yet, but discovery in the
SASL stuff will solve this, and so would discovery advertized from the
resource server.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Torsten Lodderstedt
Sent:
Marius Scurtescu schrieb:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I have a question concerning the OAuth philosophy: How many resource servers
may be managed by a single OAuth authorization server? (a) A single resource
server or (b) several of
+1 for OAuth2
Brian Eaton schrieb:
Draft 10 switched from Token scheme in the authorization header to
OAuth. I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
Token is ugly as sin, but is better than OAuth.
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
The
On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
why that? If there will be a signature proposal for resource server access,
the same (simplified?) model could be applied to the authz server's API.
Sure. Other folks have used signed URLs in this kind of
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
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
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 tors...@lodderstedt.net wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments with
different resource servers which rely
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
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 elena.loz...@rediris.es 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
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
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
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
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 some
+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
On 15 July 2010 15:59, Justin Richer jric...@mitre.org 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
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.
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
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
+1 for both
2010/7/15 Justin Richer jric...@mitre.org:
+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
On Thu, Jul 15, 2010 at 7:22 AM, Brian Campbell
bcampb...@pingidentity.com 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
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 to
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 interpretation
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 I
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 j...@jkemp.net wrote:
On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
I would like people to raise
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
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,
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 j...@jkemp.net wrote:
On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
I would like people to raise
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
On Thu, Jul 15, 2010 at 11:36 AM, Eran Hammer-Lahav e...@hueniverse.com 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
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 like
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
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
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
On Thu, Jul 15, 2010 at 1:05 PM, George Fletcher gffle...@aol.com 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
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
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.
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 server (if
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 2:16 PM, Brian Campbell
bcampb...@pingidentity.com 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
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon record...@gmail.com 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
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
Even better, thanks!
On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams m...@automattic.comwrote:
On Thu, Jul 15, 2010 at 2:11 PM, David Recordon record...@gmail.com
wrote:
On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
“The client makes the following request at an arbitrary but
Am 15.07.2010 20:14, schrieb Marius Scurtescu:
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
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
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
No normative language needed. Security consideration is the right approach.
EHL
On Jul 15, 2010, at 19:05, Brian Campbell bcampb...@pingidentity.com wrote:
Okay, I'm with you. Some text guiding the more obvious (to me anyway)
usage might still be useful. Something like,
If
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
On Thu, Jul 15, 2010 at 4:04 PM, Brian Campbell
bcampb...@pingidentity.com 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
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 authentication
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,
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
On Thu, Jul 15, 2010 at 6:35 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
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
On Thu, Jul 15, 2010 at 5:36 PM, Brian Eaton bea...@google.com 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
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 for
On 2010-07-15, at 6:45 PM, Naitik Shah wrote:
On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz balf...@google.com 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
57 matches
Mail list logo
