Nat,
All the request parameters MUST be provided through request file.
All doesn't make much sense if params can still appear in the URI, and
override the file.
What about this:
Request parameters SHOULD be provided through request file.
If it is perfectly legitimate to include some
BTW: the security threat I described in point 4) not only holds for
self-contained tokens but also for (super) handles. I consider it
especially dangerous if abusing a service causes costs for the end-user.
regards,
Torsten.
Am 03.06.2010 20:27, schrieb Torsten Lodderstedt:
I probably
+1
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Nat Sakimura
Sent: Saturday, May 08, 2010 6:45 AM
To: oauth
Subject: [OAUTH-WG] 3.4. Client Credentials text change proposal
3.4. Client Credentials
When requesting access from the
In the absence of anyone else volunteering an XML format, what would you say
to this as a proposal (because the implementation of which happens to be
simple for me):
root type=object
access_token type=stringsome access token/access_token
refresh_token type=stringsome refresh
I don't know if this is helpful or not... but there was a proposed
extension for OAuth 1.0 dealing with encoding OAuth responses in
different body formats... this can be found on the now extinct
oauth-extensions google group.
Having just implemented OAuth 2.0 web server flow, it was great to be able
to issue an opaque access token to the client. This access token is in an
encrypted format that only the resource server understands. I feel pretty
good about this approach as it lends to high security and tokens that
Thanks, George. From that I get this:
response
oauth_parameter name=oauth_tokentoken/oauth_parameter
oauth_parameter name=oauth_token_secretsecret/oauth_parameter
/response
From the text around it, it sounds like SPs were permitted to add to this
(presumably using their own
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent
auth servers is not in scope for OAuth. That said, there's nothing to
stop multiple servers to agree amongst themselves to have a
standardized format for access token- and if necessary,
This is exactly the direction UMA is headed (as George knows :-), since we
*are* trying to solve for unmooring authorization servers and resource
servers -- which we call authorization managers and hosts.
The absolute simplest thing to do is hand out tokens that are essentially
artifacts that
I'd personally rather see something flatter, even with an implied root
namespace defined in the spec. Maybe like:
oauth
access_tokenasdfasoij234f/access_token
refresh_token2f098jadfasdfasdf/refresh_token
expires_in300/expires_in
/oauth
Mirroring the key-value format for the
Hi Luke,
On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent auth
servers is not in scope for OAuth. That said, there's nothing
On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard lshep...@facebook.com wrote:
On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent
auth servers is not in scope for OAuth. That said,
On 6/4/10 9:23 AM, Justin Richer wrote:
We should solve one problem at a time. It's easy to layer structure
on top of an opaque blob in a separate spec.
+1 to this. Token structure seems like a nice idea, but it's outside
what should be dictated by the OAuth spec. We want people to be able
+1 for an optional token_format attribute/parameter
Am 04.06.2010 17:21, schrieb John Kemp:
Hi Luke,
On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server
On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:
There is more to the web than the social web Luke, and supporting multiple AS
has been a design goal of WRAP and OAuth 2.0 and is being implemented.
Whoa, I didn't say there wasn't. I agree that supporting multiple authorization
servers is a
#4 should happen as part of #3.
On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher gffle...@aol.com wrote:
Could I conclude then that we are all in agreement? :)
1. OAuth 2.0 should not require a structured token (i.e. don't break
existing use cases)
2. OAuth 2.0 should not prohibit resource
How about keeping it even more flat and compact:
oauth access_token=asdfasoij234f refresh_token=2f098jadfasdfasdf
expires_in=300 /
This also is more simple on the DOM side, just doc.root['access_token'] instead
of traversing or xpath.
Anyway, I think OAuth 2 is better served in general by
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
#4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in
the main spec. and giving it a default value, and
Am 04.06.2010 19:45, schrieb John Kemp:
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
#4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in
David, are you saying the optional parameter should be a separate spec, or
that #3 and #4 are the same thing? (I disagree with both L)
I see a new, standard token and specifying the token format are orthogonal.
The PR may accept multiple proprietary token types.
if we have the parameter in the
You earlier stated that multiple AS was out of scope. I am aligned that
using OAuth 2.0 needs to support the widely deployed social web use cases --
if you recall, I drove getting rid of the signature requirement! :)
On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard lshep...@facebook.com wrote:
On
1. ++
2. ++
3. ++
4. ++ as a part of 3., otherwise --
-- justin
On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote:
Could I conclude then that we are all in agreement? :)
1. OAuth 2.0 should not require a structured token (i.e. don't break
existing use cases)
2. OAuth 2.0 should
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
At least for the assertion flow, that's definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec and into a separate document. Perhaps that's the
Am 04.06.2010 17:04, schrieb Justin Richer:
What if you had a supertoken that was only good for getting subtokens?
In other words, only the AS knows about the supertoken (a refresh token,
perhaps?), and it allows you to get sub-tokens using the refresh flow to
access each of the different
+1
Am 04.06.2010 23:38, schrieb Brian Campbell:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andrestpe...@stpeter.im wrote:
At least for the assertion flow, that's definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec
+1
On Fri, Jun 4, 2010 at 12:36 AM, axel.nenn...@telekom.de wrote:
+1
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Nat Sakimura
Sent: Saturday, May 08, 2010 6:45 AM
To: oauth
Subject: [OAUTH-WG] 3.4. Client Credentials text change
It would be useful to understand the token type as the AS and RS server may
each generate and accept different token types
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG
+1
Sent from my iPhone
On Jun 4, 2010, at 5:38 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
stpe...@stpeter.im wrote:
At least for the assertion flow, that's definitely true. At the
interim
meeting we had some discussion about
Why?
On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote:
+1
Sent from my iPhone
On Jun 4, 2010, at 5:38 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
stpe...@stpeter.im wrote:
At least for the assertion flow, that's
On 2010-06-04, at 6:39 PM, Luke Shepard wrote:
I don't see how the extra parameter is required to support multiple auth
servers for a resource.
it is needed if there are multiple token types
Responses to Dick and Torsten:
On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
if we have the
because we use it
On 2010-06-04, at 6:40 PM, Luke Shepard wrote:
Why?
On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote:
+1
Sent from my iPhone
On Jun 4, 2010, at 5:38 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
31 matches
Mail list logo
