On 2010-02-03, at 11:21 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Wednesday, February 03, 2010 11:19 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda
On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote:
hat type='chair'/
On 2/3/10 12:46 PM, Dick Hardt wrote:
Wanting to discuss technical details when there does not seem to be
consensus on the problem we are solving was my Titanic reference.
Remember, these interim meetings
On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:
Blaine Cook wrote:
- Why are signatures needed?
1) For authentication
2) For ensuring integrity
3) For non-repudiation
Those are the general capabilities of signatures. Why does the Client need to
sign the request / token? is the
Hi Eve
Looking at the WRAP oriented comments in the spec, here are some comments /
questions:
Note
WRAP doesn't seem to say HTTPS is required for the user authorization URL; is
this a bug in the WRAP spec? If not, is it a good idea for us to profile it in
this way? Finally, is this the right
Thanks Eve, comments inserted ...
On 2010-03-04, at 12:51 PM, Eve Maler wrote:
As requested on today's call, here's a description of the places where UMA
seems to need more than what the WRAP paradigm offers (both profiling and
extending), based on the proposal at:
On 2010-03-08, at 1:09 PM, John Kemp wrote:
On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
2) Client signed tokens are no more secure in MITM attacks than bearer
tokens for on-the-fly attacks. If the attacker can disrupt the channel, the
attacker can take the signed token and use
On 2010-03-05, at 6:57 AM, Eve Maler wrote:
More below...
On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote:
Thanks Eve, comments inserted ...
On 2010-03-04, at 12:51 PM, Eve Maler wrote:
As requested on today's call, here's a description of the places where UMA
seems to need more than
On 2010-03-09, at 7:05 AM, Eve Maler wrote:
It's a good idea to give guidance on how the scope parameter should be used.
That way, it will help avoid abuse of the parameter for other purposes, and
clashes if different deployments are using it in different ways. (I suspect
that the
On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:
On Tue, Mar 9, 2010 at 3:50 PM, David Recordon record...@gmail.com wrote:
Ideally we'd limit the length of access and refresh tokens as well as
client keys and secrets to no more than 255 characters (a one byte
varchar in MySQL).
Is this
On 2010-03-09, at 6:24 PM, Ethan Jewett wrote:
I think it would make sense to advise client library and application
programmers to provide for the possibility of and storage of large
tokens. We should probably reference examples of tokens seen in the
wild and mention the technical
a good thing to include.
Ethan
On Tue, Mar 9, 2010 at 8:14 PM, Dick Hardt dick.ha...@gmail.com wrote:
On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:
On Tue, Mar 9, 2010 at 3:50 PM, David Recordon record...@gmail.com
wrote:
Ideally we'd limit the length of access and refresh
On 2010-03-09, at 7:50 PM, David Recordon wrote:
On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt dick.ha...@gmail.com wrote:
I understand the desire to set a max length that can easily fit into a DB.
There are lots of other items I think the developer is storing that can be
long as well, like
On 2010-03-23, at 12:05 PM, Chuck Mortimore wrote:
No worries – I figured it would be easier to push for it’s inclusion if the
work were minimal.
We will definitely need to implement this style of profile, as will many
others, so it’s essential it ends in some spec. Personally I’d
into the spec as soon as possible. I have the next 4 weeks
set aside for making significant progress on this document.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Eaton
Sent: Wednesday, March 24, 2010 10:25 AM
To: Dick Hardt
Cc
On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
On 4/2/10 3:27 PM, Dick Hardt dick.ha...@gmail.com wrote:
There are times when a resource may have different scope for different kinds
of access. realm != scope
No. Realm is a subset. It is what people define as the protected
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.
. On the other hand, limiting the sub-domain
can make scalability harder.
Care to propose text?
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dick Hardt
Sent: Sunday, April 18, 2010 9:22 PM
To: OAuth WG
Subject: [OAUTH-WG] Clarification
On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote:
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Dick Hardt
Sent: Sunday, April 18, 2010 9:20 PM
To: OAuth WG
Subject: [OAUTH-WG] Issue: state in web server flow
Why
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
+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-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
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-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-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
...@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
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
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
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
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
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
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
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
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
/
__
-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
+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
+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
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
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
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
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
, 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
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
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
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
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
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
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
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
1 - 100 of 417 matches
Mail list logo
