On 2011-01-05, at 7:01 PM, Francisco Corella wrote:
--- On Wed, 1/5/11, Marius Scurtescu mscurte...@google.com wrote:
This seems to be saying that the user's machine has a Web
server running on it which is reachable from the Internet by
sending an http request to the redirection URI.
On 2010-10-26, at 4:33 PM, Mike Jones wrote:
Having a simple discovery method for services and resources is key to
enabling many Internet scenarios that require interactions among parties that
do not have pre-established relationships. For instance, if Joe, with e-mail
address
Note there will be three documents not two.
The suggested change does not address the issue that myself and others had
raised with having signatures be in the core. The suggestion was that having
signatures be a different spec made them reusable by other groups and enabled a
more comprehensive
On 2010-09-30, at 11:33 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Thursday, September 30, 2010 7:45 AM
The suggested change does not address the issue that myself and others had
raised with having signatures be in the core
On 2010-09-26, at 11:02 PM, Eran Hammer-Lahav wrote:
Clearly, this group is making choices based on the kind of applications using
OAuth 1.0 today. The decision to focus on bearer tokens came from specific
experiences and types of consumer web services.
Any other applications are
-Lahav e...@hueniverse.com
wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Sunday, September 26, 2010 11:21 PM
What I absolutely object to is presenting a specification that to a new
reader will read as if bearer tokens are the default way to go
As others have stated and I agree with, you also need an extension mechanism so
that other signature algorithms can be used. If there is no extension
mechanism, then the spec is saying this is the only signature mechanism
possible.
-- Dick
On 2010-09-26, at 11:44 PM, Eran Hammer-Lahav wrote:
On 2010-09-27, at 8:14 AM, Eran Hammer-Lahav wrote:
That goes without saying.
No it does not. We are talking about normative specifications.
Yes. Does this satisfy your concerns?
Depends on the quality of the extension mechanism.
Many of the people wanting signing want something stronger
Myself and others feel that a spec for how to sign a request would be useful
for other specifications. As I noted in a previous email, there was dismay when
the signing of an OpenID message was very similar, but different than the
signing in OAuth 1.0A.
Signing messages was a huge stumbling
On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use
On 2010-09-25, at 7:52 PM, Eve Maler wrote:
It seems like you figured it out pretty quickly, given the message you sent
immediately after. :-)
Referencing another spec from the core spec using normative text is
effectively including it by reference. I meant that I'm sympathetic (+1) to
Did you intentionally decide not to support encrypting the token?
On 2010-09-23, at 5:22 PM, Mike Jones wrote:
Recognizing that there is substantial interest in representing sets of claims
in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token
(JWT) spec for that
:
I’d be open to a proposal for also supporting encryption. The draft was
intended to be a starting point for productive discussion – not a finished
product.
Your thoughts?
-- Mike
From: Dick Hardt [mailto:dick.ha...@gmail.com
subjective to how important one think
it is.
EHL
On 9/24/10 10:43 PM, Dick Hardt dick.ha...@gmail.com wrote:
I don't follow your logic ... or perhaps I don't see why the spec needs to be
written in more than two parts.
For example, the current spec does not specify the format
-1 in core
+1 to being referenced in core and being a separate document
On 2010-09-23, at 6:43 PM, Eran Hammer-Lahav wrote:
Since much of this recent debate was done off list, I'd like to ask people
to simply express their support or objection to including a basic signature
feature in the
the spec into more than two
parts. Basically, I will be creating a version that does not force anyone to
read anything they might not care about. Clearly, we shouldn’t based
editorial decisions on what you want to read :-)
EHL
On 9/24/10 5:21 PM, Dick Hardt dick.ha...@gmail.com wrote
On 2010-07-27, at 12:34 AM, Nat Sakimura wrote:
I have a fundamental question.
While separating signature and payload by a dot . seems ok,
I still have not the answer for the question why not make everything
into JSON and base64url it?.
bloat from base64 encoding twice
BTW, some of
Thanks for sharing Paul!
On 2010-07-26, at 3:18 PM, Paul Tarjan wrote:
Facebook released an early version of the proposed signature method, with the
aim of getting real-life implementation experience. We are not currently
using this for protected resource requests, but rather more like if
On 2010-07-17, at 12:51 PM, Eran Hammer-Lahav wrote:
client_credentials worked fine before. I'll just replace none with that. No
one had an issue with the name in -05.
+1
___
OAuth mailing list
OAuth@ietf.org
useful in many
other architectures and protocols.
-- Dick
Dirk.
On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt dick.ha...@gmail.com wrote:
Hi Dirk
Responding to this now that you are back.
From:
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
(which
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
I agree we don't want to end up like other protocols that were too generic. :)
The use case I am arguing for is sending encrypted tokens. Higher levels of
assurance require this and various people brought this up as a requirement when
WRAP was presented at IIW 09B.
-- Dick
On 2010-07-10, at
On 2010-07-10, at 1:42 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-10, at 1:21 PM, David Recordon wrote:
On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt dick.ha...@gmail.com wrote:
* the signature comes before the payload
* we
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
We don't think base64url will work, because the most common error we'll see
is that developers forget the url part and just do plain base64, and
that's not sufficient because the stock set includes +.
I think forgetting to url-decode is more
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s in the token, then it is easy for someone helping to spot
the problem. also easy for servers to send back an error message
On 2010-07-03, at 11:28 AM, Luke Shepard wrote:
* We'd like the signature first (so you can left split instead of right
split)
What are the advantages of left split vs right split?
Built in split function with a limit is more common, which makes the left
split easier.
Size
On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
I think Naitik is saying that accidentally doing base64 and not base64url
will send some '+'s along.
if there are '+'s
While the AS implementor can infer the request by the parameters, I prefer the
programmer explicitly state what she is doing. Thinking of it as a method
parameter rather than a type parameter makes more sense to me. Similiarly, HTTP
has GET, POST, PUT etc. even though you could differentiate
(type vs method). Are there any objection to
defining a parameter for the client authentication method? Any views about
using this parameter with an HTTP authorization header?
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Monday, June 28, 2010 12:25 PM
To: Eran Hammer-Lahav
I vote for (3) unless a good (4) is suggested.
On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote:
Over the past year many people expressed concerns about the use of the
‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC
2617 as required, and is allowed to have
The current spec defines scope (when the scope variable is introduced) as:
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the scope parameter
is defined by the authorization server. If the value
, June 24, 2010 8:15 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas
Rosenstock; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
I'm in favor of having a spaces separated list of tokens.
The only case I can think of where the client needs
To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas
Rosenstock; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
I'm in favor of having a spaces separated list of tokens.
The only case I can think of where the client needs to handle
the scope as anything other than
Would you elaborate on your reasons here? Do you think we have enumerated all
the possibilities?
On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote:
I would rather limit the ability to extend the two endpoints beyond their
current architecture, and instead, allow others to specify new
and would like to keep the
process as light as possible (i.e. no registration at all).
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dick Hardt
Sent: Friday, June 25, 2010 8:50 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: OAuth WG
parameter (such as language) is
a good thing to support, and by requiring review, only parameters that don't
change the overall design will be approved.
EHL
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Friday, June 25, 2010 11:13 AM
To: Eran Hammer
The RFC term is base64url which turns up much better results when searching.
URL safe base64 is also a good search term.
Note that the token may also be included in the HTTP header. base64url encoding
works well for HTTP headers. Note that the token is opaque to the client, so
being plain text
10:49 AM
To: Dick Hardt
Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
Wasn't there some concensus that URIs would be good for scope? They
have in-built namespacing ...
Lukas
2010/6/23 Dick Hardt dick.ha...@gmail.com
On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the scope parameter
is defined by the authorization server. If the value contains
On 2010-06-21, at 11:03 PM, David Recordon wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
it is the ID of the key, not the client -- used to rollover keys
Does websafe-base64-encoded mean
One of the modifications I concluded to do to WRAP was to add in the type
parameter. I was happy to see if in David's draft.
Even though redundant in some ways, it make it very clear to both the client
and server what is intended.
+1 for putting it back in.
On Mon, Jun 14, 2010 at 11:23 AM,
Per an earlier comment, type might not be the best name for the parameter.
Perhaps method might work and adds a clear extension point for other types
of calls?
On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt dick.ha...@gmail.com wrote:
One of the modifications I concluded to do to WRAP was to add
Thanks for writing this up Dirk.
I would suggest that the token be:
payload . envelope . signature
This enables the payload to be encrypted and independent from the envelope.
Token signing, verification, encryption and decryption code can then be generic
and not understand the
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Eaton
Sent: Monday, June 21, 2010 9:49 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures
On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt dick.ha...@gmail.com wrote:
Thanks for writing this up Dirk
+1
On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott andrewarn...@gmail.com wrote:
For an application I'm building, the installed client app will have
intermittent windows of time where it can obtain a (non-OAuth) assertion for
user identity.
right to say it. - S. G. Tallentyre
On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt dick.ha...@gmail.com wrote:
+1
On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott andrewarn...@gmail.com
wrote:
For an application I'm building, the installed
Are you envisioning the client makes a call to AD to get an assertion where the
call is automagically authenticated as the user by NTLM?
What do you envision being the relationship between the AS and AD? What
authority does the AS have? How long is the refresh token valid for?
I think you
+1
On 2010-06-10, at 1:29 PM, Eran Hammer-Lahav wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment)
using JSON.
My
/
__
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Dick Hardt
Sent: Friday, June 04, 2010 9:59 PM
To: Luke Shepard
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping
because we use it
On 2010-06-04, at 6
Background: The username / password flow can be used to brute force attack a
system to find valid credentials. A captcha is presented to slow the attack
down -- similar to what happens when you log in with an invalid password on a
webpage.
The captcha would be displayed by the app for the user
You are pointing out Marius point -- he wants to require registration. If the
redirect_uri is not registered, the only party that can detect that it is the
right URI is the user. The AS can only show the user the redirect_uri passed
over.
-- Dick
On 2010-06-07, at 5:31 PM, Chuck Mortimore
On 2010-06-07, at 1:24 PM, Thomas Hardjono wrote:
What if the username/password (or PIN) was used to release a secret (located
in an OTP dongle) or to exercise a secret key (symmetric or asymmetric)
located in a smartcard or TPM chip?
Reading Section 3.8, it seems it covers these cases
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,
format
Thanks,
George
On 6/4/10 12:45 PM, Luke Shepard wrote:
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
:
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
+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
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
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
On 2010-06-03, at 7:54 AM, Thomas Hardjono wrote:
Dick, Brian,
Thanks for the clarification.
- Is the Assertion Flow designed only for the STS,
or can it be used with other identity providers (non-WSS).
It can be used with any tokens. I use the STS term to clarify the design
pattern.
On 2010-06-03, at 8:20 AM, Peter Saint-Andre wrote:
On 6/3/10 8:54 AM, Thomas Hardjono wrote:
PS. Compared to the details of RFC4120 and even
to the old ISAKMP in the IETF, the current
OAuth2.0 draft-05 spec appear to be a high-level framework
that needs to be instantiated/profiled.
At
The Assertion Flow is for the AS to act as an STS where one token is
exchanged for another. This allows the PR to not have to worry about
different kinds of tokens and to only deal with tokens issued by an AS.
Lisa: a real world example of your use case would make it easier for how you
got to the
I don't recall any discussion at the level of detail that Torsten is asking
about.
My inclination would be the Client would include the what was returned in
WWW-Authenticate in the access request call.
On Tue, Jun 1, 2010 at 11:47 AM, Peter Saint-Andre stpe...@stpeter.imwrote:
We discussed
I think so. In WRAP the verification code was RECOMMENDED one time use.
On 2010-05-30, at 9:38 AM, Andrew Arnott wrote:
I was reviewing 3.6.2. Client Requests Access Token and it occurred to me
that there's no requirement in the spec (that I can find) that a given
callback URI and
Are you referring to my OpenID v.Next NewSocialService scenario?
What issues do you see doing this in v.Next rather than OAuth?
Using OpenID allows the client/RP to only discover the user's OP, which
knows where the user's calendar / address book is.
Having the OP as an intermediary allows it
Frustration devs have with URL encoding. This is the core motivation to using
JSON as the AS response format.
-- Dick
Begin forwarded message:
From: Andrew Badera and...@badera.us
Date: May 23, 2010 2:57:44 PM PDT
To: twitter-development-t...@googlegroups.com
Cc: oa...@googlegroups.com
On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote:
But back to my original email, what are the use cases for 'immediate' without
identity?
The client may not have any indication of which user it is, but want to check
if it is a user they already know. They can do a check immediate, get the
: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Sunday, May 23, 2010 8:01 PM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] 'immediate' without identity
On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote:
But back to my original email, what
On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Monday, May 24, 2010 7:35 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] 'immediate' without identity
You were looking
Not sure why you want to pull the OAuth token parameters from the Kerberos
token.
Are you envisioning the Protected Resource is a Kerberos Client?
On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono hardj...@mit.edu wrote:
I'm still a newbie to the OAuth and WRAP discussions, so please bear
The image can be protected by both. Do you expect OAuth to be used with user
present in the browser?
On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:
Why can’t an image be protected with both Basic and OAuth? In this case the
browser is the OAuth client.
EHL
From: Dick Hardt
...@google.com]
Sent: Monday, May 10, 2010 12:49 PM
To: Eran Hammer-Lahav
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] modifying the scope of an access token
On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
This would only work for the client
, May 10, 2010 12:49 PM
To: Eran Hammer-Lahav
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] modifying the scope of an access token
On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
This would only work for the client credentials flow
On Tue, May 11, 2010 at 11:31 PM, Luke Shepard lshep...@facebook.comwrote:
FWIW, Facebook does not do strict equality matching on redirect_uri. We
accept any redirect_uri that has either:
- its prefix is the registered url
- or it is a special facebook.com/xd_proxy.php url, with an origin
James: An important capability of the refresh token is that it *can* be a
self contained token in that is not an id, but a signed token that can be
examined and acted upon on presentation.
Torsten: enabling a client to revoke a refresh token looks like a useful
mechanism. I anticipate it will be
Not sure if you intended this, but you are mixing user present and user not
present access control.
I do NOT think we want OAuth protected images to be the same as Basic auth
protected images. I do think OpenID protected images and Basic auth are
similar. With OAuth today, the user has granted
Note that you could accomplish this functionality with the 'modify' proposal
I posted where an access token with a different scope could be requested
could be used to acquire a second token that has less privileges and would
be appropriate over HTTP.
To recap, 'modify' is like 'refresh' except
Looking over the previous threads, I don't think an important capability was
pointed out that we want to preserve:
The AS may NOT need or want to know where an access token is used. In other
words, the access token could be viewed as a claim that can presented to an
arbitrary resource to gain
Below is proposed text where a token is referred to as an identifier.
Here is the definition of identifier from RFC 4949:
$ identifier
(I) A data object -- often, a printable, non-blank character
string -- that definitively represents a specific identity of a
system entity,
On 2010-05-16, at 3:46 PM, oauth issue tracker wrote:
#6: Make automated self-registration of unique clients possible
-+--
Reporter: e...@…| Owner:
Type: enhancement | Status: new
On 2010-05-16, at 5:20 PM, Manger, James H wrote:
Dick,
James: An important capability of the refresh token is that it *can* be a
self contained token in that is not an id, but a signed token that can be
examined and acted upon on presentation.
Defining refresh_token as a URI does not
On 2010-05-10, at 1:11 AM, Pid wrote:
On 10/05/2010 07:57, Joseph Smarr wrote:
1. Server Response Format
I vote for B, though I could live with C. (A would make me sad though)
We've had a healthy and reasonable debate about the trade-offs here, but
I think the main counterargument for
On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:
DEADLINE: 5/13
I would like to publish one more draft before our interim meeting in two
weeks (5/20). Below are two open issues we have on the list. Please reply
with your preference (or additional solutions) to each item. Issues with
On 2010-05-09, at 3:25 PM, Eran Hammer-Lahav wrote:
3.2.1.1. Access Token Response
expires_in
OPTIONAL. The duration in seconds of the access token
lifetime.
refresh_token
OPTIONAL. The refresh token used to obtain new access tokens
using
There has been some discussion about modifying the scope of the access token
during a refresh. Perhaps we can add another method to what the AS MAY
support that allows modifying the scope of an access token. Type of request is
modify and the scope parameter is required to indicate the new scope
Twitter has an interesting use case that may become common: one client needs to
delegate access to another client. Similar to the 'modify' method where the
scope of the access token can be modified, the 'delegate' method allows a
client to request delegation to another client (the delegate).
Right now it depends on the server.
The spec should clarify that. Suggested wording:
If the client has previously registered a redirection URI with the
authorization
server, the authorization server MUST verify that the redirection URI
received matches the registered URI associated
On 2010-05-01, at 3:48 PM, Luke Shepard wrote:
I agree with approach #3.
As for the delimiter, I'm fine if the spec wants to do space-delimited.
Just FYI Facebook will also continue to support and document commas in
addition to whatever the spec says, because spaces are typically
On 2010-04-30, at 9:02 AM, Yaron Goland wrote:
I actually have a preference for application/x-www-form-urlencoded but it's
not overwhelming, the key thing I believe we need to do is have exactly one
request/response format. In other words, I don't believe we should use one
format for
the request
parameter and schema of the various reply formats.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, April 19, 2010 4:48 AM
To: Eran Hammer-Lahav
Cc: Dick Hardt; OAuth WG
Subject: Re: [OAUTH-WG] application/x-www-form
+1 as starting point. :)
On Tue, Apr 27, 2010 at 11:55 AM, Peter Saint-Andre stpe...@stpeter.imwrote:
On 4/26/10 3:14 PM, Marius Scurtescu wrote:
+1
I am assuming this means that the current draft will become the
initial check point, version 00. Is that correct?
Correct.
/psa
On 2010-04-19, at 9:46 PM, Peter Saint-Andre wrote:
On 4/18/10 6:46 PM, Dick Hardt wrote:
Given the practice that the authorization endpoint and the redirect_uri
can contain URI query parameters, then differentiating between
application specific query parameters and OAuth protocol
The scope parameter was included in WRAP at the request of library and AS
implementors to standardize a commonly included parameters.
The client_id parameter seems similar to the scope parameter. The meaning of
client_id is not defined in the spec and is AS specific. A client_id that a
developer
think we need to add a bit more definition to the scope parameter.
Maybe as simple as a comma-separated list of strings.
On Sun, Apr 18, 2010 at 6:12 PM, Dick Hardt dick.ha...@gmail.com wrote:
The scope parameter was included in WRAP at the request of library and AS
implementors to standardize
dubios of no oauth_
prefix after hacking on a draft implementation their opinion has
changed. They're now really enjoying shorter and cleaner paramater
names and found them to be easier to document and no more difficult to
implement.
On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt dick.ha
The spec describes the access token as an identifier. One of the key
capabilities of WRAP was that the token could be self contained. The PR could
make an access control decision by examining the access token and not calling
the AS.
The token is referred to as an identifier in the Abstract,
General comments:
Putting the flow description, diagram and steps in the section with the spec
work well.
Use of server term. In numerous places, the term server is used instead of
authorization server or resource server (maybe even web server). To avoid
ambiguity, I would suggest the term
On 2010-04-18, at 9:04 PM, Marius Scurtescu wrote:
On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt dick.ha...@gmail.com wrote:
Since calls to the token endpoint use POST, there can not be any confusion
between the parameters in the body of the message and URI query parameters
Unfortunately
Some AS will match part of the URI to what was registered, some require
everything up to the start of a query. The spec needs to clarify how much of
the URI needs to be matched, or state it is AS specified.
-- Dick
___
OAuth mailing list
I recall some earlier discussion on calling the scheme Token vs OAuth and see
that it is now Token per the example:
Authorization: Token token=vF9dft4qmT
Would explain or point out the logic of using Token rather than OAuth?
A related question: is the scheme case
+1 to #1
On 2010-04-18, at 9:35 PM, Luke Shepard wrote:
1/ We leave the scope parameter as an Auth Server-specific, opaque parameter.
2/ We all agree on a format and spec for the scope parameter.
3/ We drop the scope parameter and make each server define their own,
non-standard scope param.
301 - 400 of 417 matches
Mail list logo
