On Mon, Nov 26, 2012 at 7:22 PM, Shane B Weeden wrote:
> My understanding is that it is considered a best practice to rollover a
> refresh token on each use - that is when a refresh token is used, both a
> new access token and a new refresh token are issued, and the old refresh
> token is revoked
On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote:
> We've had OAuth2 running successfully for a while now, but we're finding
> that mobile applications have frequent problems with the refresh flow where
> a refresh request is made, but the network connection fails before the new
> AT/RT pair is
On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wrote:
> Why would you re-issue a refresh token every usage? What's the use case
> where this makes sense?
It's key rotation built into the protocol. Even if a refresh token is
stolen, it's going to become useless to the attacker very quickly.
On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav wrote:
> How exactly? They are not confidential by nature, being received via
> redirection in the URI query. I know what this sentence is trying to
> accomplish but not sure how to do that with normative language. SHOULD
> doesn't really work
On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin wrote:
> I was responding to the structure question only. The token text is
> questionable sine the tokens are opaque to the core, seems like the token
> write-up better belongs in the threat model document. Developers of the
> various token specs
On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin wrote:
> When we constructed the current structure in Prague we thought that
> structure best fit the needs of a implementer, so my preference would be to
> keep it as it is now but, Torsten / Mark / Phil also may have feedback.
>
Really?
The curr
On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer wrote:
> You can still use the access code (web server) flow within a JavaScript
> application, just without a reliable client secret. The point of the
> "implicit" flow was to save a roundtrip to the server for light clients
> with limited lifespans,
On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg <
igor.faynb...@alcatel-lucent.com> wrote:
> **
>
>
> On 6/16/2011 4:51 PM, Brian Eaton wrote:
>
> On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> If those people
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> If those people have reasonable means in place to protect secrets on
> deployment channels and in the local installation - fine. I would be eager
> to learn more about those means because I would be wille
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> no I'm saying people will use real secrets and rely on them - just as with
> OAuth 1.0
>
=)
People are going to ignore what the spec says on this. If you read through
the mailing list threads on this t
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> No, it's not simpler nor clearer. Such a client secret is useless, so the
> security implications have to be explained anyway.
>
The issue really isn't the security implications being unclear; the issue
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> **
> Certainly not. Are we discussing to make client authentication required
> just for syntactical purposes?
>
That is what I'd like to see.
>From my perspective, no harm is done by making client authentic
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> -1 making client authentication required at the access token endpoint
>
> Client authentication is useful in some situations to raise the security
> level. But requiring it will either keep out native apps or
On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav wrote:
> This is nice on paper but doesn’t work.
>
I have to agree. It doesn't matter what the spec says on this point. No
one is going to take advice from the spec about what the text on their
approval page ought to say.
_
On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav wrote:
> 1. Why not require the registration of a redirection URI for implicit grant
> requests, removing the redirect_uri parameter completely from the request
> (the client can still use the state parameter)?
>
As others have stated, this is a
On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono wrote:
> >>> Requiring client authentication doesn't defend against
> >>> attacks directly; it makes recovery after a successful
> >>> attack easier.
>
> I presume you mean direct attacks on the authorization server.
>
Also attacks on the clients.
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav wrote:
> Your comment was that having client authentication makes it easier to
> recovery from an attack. I don’t understand how the comments below about
> changing client secrets every 30 days are relevant. Are you suggesting to
> wait until the
On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav wrote:
> How does it make recovery easier? Why is revoking refresh token any harder
> than changing client secret?
>
Changing a client secret can be done without disrupting users. You can even
schedule it, do it every 30 days as part of your gen
On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden wrote:
> Brain - can you elaborate on that a little? Are you suggesting that clients
> that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
> "requiring client authentication"?
>
Or use random secrets. Whatever floats your boat a
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav wrote:
> So basically, it is authentication on top of bearer credentials to achieve
> another level of security. Are we just assuming that stealing the refresh
> token will be harder than stealing the client credentials? Seems a bit
> optimistic.
On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav wrote:
> > I suspect another choice of words would be useful there. Implicit grants
> rely
> > on the browser's authentication of the receiving web site. When https is
> > used, that authentication is fairly strong.
>
> "authentication of the re
> We have one grant type without client authentication (implicit)
I suspect another choice of words would be useful there. Implicit grants
rely on the browser's authentication of the receiving web site. When https
is used, that authentication is fairly strong.
> I would like to go back to requi
okens are credentials used to access protected
> resources. Refresh
> tokens are credentials used to obtain access tokens.
>
> -bill
>
>
> --
> *From:* Brian Eaton
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Sent:* Wednesday, June 15, 201
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav wrote:
> I would like to add a quick discussion of access token and refresh token
> recommended deployment setup, providing clear guidelines when a refresh
> token SHOULD and SHOULD NOT be issued, and when issues, how it is difference
> from the
Agreed, it's nuts to return a refresh token for that flow.
Eran, why is this still in the spec? You agreed to remove it almost a
year ago. It's come up multiple times since then.
http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html
Cheers,
Brian
On Fri, Jun 3, 2011 at 9:45 AM, Mar
On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre wrote:
> I'm not thinking about your use case, but things like enterprise
> deployments in high-security environments where every person and every
> software application has a certificate or is otherwise provisioned for
> authentication with the au
On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre wrote:
> I think the SHOULD we had originally is probably fine -- with the
> understanding that "SHOULD" means "you really ought to do this unless
> you have a good reason not to". I think one such really good reason
> might be a authorization serv
On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre wrote:
> I think I might have misunderstood that text -- I took it to be talking
> about the client's authentication with the authorization server, not the
> client's authentication with the resource server.
No, you understand perfectly. We're t
On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills wrote:
> In practice there are an extremely small number of cases where this is
> actually done right, and legions of cases where it's done wrong. Industry
> just doesn't get this right often enough to rely on it.
>
Well, "rely" is a strong-term.
On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono wrote:
> (a) Oauth2.0 today is designed for low-assurance environments. So I think
> the WG is wasting a lot of time in trying to address whether the Client can
> keep secrets. The WG should just assume that the problem of keeping secrets
> is out
On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono wrote:
> Well, not to belabor this point :) but in Kerberos it is the proof of
> possession of the client secret key which _is_ the authentication mechanism.
> There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the
> user via D
Hey Peter -
I haven't read all of your comments yet, but I wanted to clarify one point
about client impersonation and installed apps. The cuirrent text is
unrealistic, but your request would push it the wrong way. CC'ing Torsten
as well.
-
OLD:
The authorization server SHO
On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward wrote:
> Verifyable and Forgeable were the best terms we've come up with so far in
> attempt to put a label on "apps that can keep secrets" and "apps that can't
> keep secrets," respectively.
You might be on to something there. There are two ways
On Wed, Jun 1, 2011 at 9:11 AM, William J. Mills wrote:
>> - native apps always use the authorization code grant
>
> I don't like this if it means I can't use passwrd grant for stuff like IMAP
> clients.
Sorry, didn't mean to suggest that password grants would go away. The
business need is clear
On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
wrote:
>> - ignore the problem and leave the spec vague and insecure.
>
> Could you please describe what you consider "insecure"?
As an example, optional client authentication in the authorization
code flow makes the web server flow much less s
fic secret which we can issue
> through an admin controlled provisioning process. In this case we can also
> escalate capabilities as we’re reasonably sure we’re talking to an instance
> of the client.
>
> For JS Apps we support the implicit grant with no refresh token
>
> -cm
On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt
wrote:
> I'm getting confused. This thread is about native apps. So why discuss
> security considerations for web apps here?
They overlap because they both use refresh tokens. =/ When people
propose changes that impact refresh tokens, it impac
On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore
wrote:
> This is one reason we’ve favored implicit for native apps.
OK, so are you using the implicit grant for both web apps and native
apps...? I'm trying to figure out if you need two flows are three.
- web server flow
used with real secret
On Tue, May 31, 2011 at 11:47 PM, Kris Selden wrote:
> If a provider chooses to do that though, in the attack you described, they
> could still revoke the refresh token to stop the abuse when it is discovered,
> and that is still easier in my opinion than rotating a client secret but yes,
> all
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
wrote:
> It’s not entirely necessary; I’m just having a tough time figuring out any
> practical difference between the implicit grant flow, and the webserver flow
> with no credentials. In general I agree with your points, but I think we
> have a
On Tue, May 31, 2011 at 10:39 PM, Kris Selden wrote:
> Why can't you just revoke the refresh token for a client when you change the
> client secret?
>
> Is it not easier to revoke a token than it is to rotate the client secret
> (which is usually configured or embedded in the client whereas the
On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
wrote:
> Updated in language I just sent out – thanks.
>
> On that note, we currently return refresh_token using the implicit grant
> type under certain controlled circumstances. Facebook in turn uses the
> implicit grant type, and simply issues
As I said in the other note, after reading through the security
considerations section a couple of times, I think it could benefit
from a different organization. Specifically
- keep the introduction, it’s awesome.
- write new sections for each of the following
1) Authorization Tokens
2) Web
I just read over the whole of the draft for the first time in a while.
I looked it over mostly for
a) places where spec and reality were going to have trouble intersecting
and
b) places where security advice would be useful
and
c) grammer and speling, because I notices things like that
Mos
On Mon, May 2, 2011 at 11:33 AM, Freeman, Tim wrote:
> The issues around redirect_uri seem muddled to me.
>
Yeah. =/ It's unfortunate. I think the problem is that implementers
disagree on what type of redirect uri validation to do, so the spec has
papered over the inconsistencies with muddled
Hey Andrew -
Two-legged OAuth is a very confusing term. I've tried to stop using it,
because it means so many different things to different people. I'm not 100%
sure what your use case is...
The current OAuth2 draft handles traditional client-server authentication
with the client credentials fl
On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren wrote:
> Is this required or not? In the example
> http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed
> in the example but not itemized as optional or required. It's not in the
> example for refreshing tokens
> http://tools.iet
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt wrote:
> Very quickly here is the attack...
> 1) Paul starts dance at good Client & good AS, App requests authorization.
> Note: outbound call is secure, but returned redirect is not.
For the record, we haven't had particular problems with installed app
On Mon, Apr 4, 2011 at 9:52 AM, Phil Hunt wrote:
> As Prateek clarified in the previous message to Francisco, SAML also uses
> SHOULD, but artifact security is achieved by an additional
> counter-measure...
>
> The identity provider MUST ensure that only the service provider to whom
> the messag
OAuth Bearer Token draft
>>
>>So is a different namespace for each new mechanism right, or should a
>>parameter be added to parallel the authorization scheme name? Seems like
>>it would be clean to define oauth_scheme and use the same value as
>>defined for the auth
I don't think the advice from the OAuth 1.0a spec is wrong:
http://oauth.net/core/1.0a/#anchor38
"Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an at
On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav wrote:
> ‘oauth_token’ is limited to bearer tokens only. It is not suitable for
> anything else.
Except that OAuth 1.0 already went out using oauth_token for signed requests.
___
OAuth mailing list
OAut
My two cents:
We've already taken three user visible outages because the OAuth2 spec
reused the "oauth_token" parameter in a way that was not compatible
with the OAuth1 spec.
Luckily they were all caught before they caused serious damage.
Generic parameter names are not useful. They lead to con
On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav wrote:
> How do you envision this being incorporated into v2? Just section 5 or the
> entire document?
>
My two cents: rather than dedicating a single section of the core doc to
security considerations, smaller sections should be added to individ
Has anyone stepped up to start writing security considerations yet?
Now that the organization is back to tracking different use cases
using different flows, I think it's feasible and would like to
contribute.
___
OAuth mailing list
OAuth@ietf.org
https:/
How do we reconcile "Bearer" with "Negotiate", "NTLM", "Basic", and
"GoogleLogin"? All of those examples are widely deployed and use
bearer tokens in Authorization headers. Should all of those switch to
using the "Bearer" scheme as well?
Tokens issued via OAuth will require specific validation l
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote:
> Can you share what the actual request looks on the wire? How are you passing
> the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
>From memory, the
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote:
> Can you share what the actual request looks on the wire? How are you passing
> the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
>From memory, the
On Wed, Jan 26, 2011 at 9:07 AM, Eran Hammer-Lahav wrote:
> Can you share an actual example of how you are authenticating *both* the
> resource owner and client in a single request?
That's not a business requirement.
So the desired flow goes like this:
kerberos (or other magic sauce) authe
On Tue, Jan 25, 2011 at 10:58 PM, Eran Hammer-Lahav wrote:
>> What's the difference from a conceptual point of view? In my opinion, the
>> resource owners password is used for both, authenticating the resource
>> owner and authorizing the token issuance.
>
> The resource owner is not present and t
27;t seemed
like a high-value proposition.
On Wed, Jan 26, 2011 at 12:45 AM, wrote:
> Hi Brian,
>
> you identified the use cases correctly. No interactive user-consent would be
> required.
>
> Regards,
> Torsten.
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
&g
Hey Torsten -
I'm trying to parse through these messages to figure out the flows
you're interested in.
I think you're aiming for rules like this one, right?
kerberos authentication -> access token
or
digest authentication -> access token
And furthermore your intended use cases are applica
hat category. Even you are not going to use it.
>
> EHL
>
>> -Original Message-
>> From: Brian Eaton [mailto:bea...@google.com]
>> Sent: Wednesday, January 19, 2011 6:21 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Proposal
On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav wrote:
> Since no one else (other than you) showed any interest in keeping this
> section in for the past 9 days, I assume they don't care. I will remove this.
This is an unfortunate assumption, and I think it could do serious
damage to the spec
On Wed, Jan 19, 2011 at 6:11 PM, Eran Hammer-Lahav wrote:
> Will this HTML5 magic involve making a single authorization request
> (redirection) or two?
It's not magic, it's window.postMessage().
It's an authenticated low-latency channel between windows or iframes.
There is more than one way to
On Wed, Jan 19, 2011 at 6:05 PM, Eran Hammer-Lahav wrote:
> Can I take this as an endorsement for dropping it? It feels very experimental
> and should be easy to add as an extension.
I defer to the several other people who were interested in this
approach. From memory, that's Brian Ellin, Luke
On Tue, Jan 11, 2011 at 4:40 PM, Brian Eaton wrote:
> On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav
> wrote:
>> But that's just an annoying implementation detail.
>
> Yes. The user-agent flow is a set of annoying implementation details
> that are very, very usef
On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
wrote:
> Do you see any need to restrict the power of this token or is it as powerful
> as the tokens obtained using the code? I'm asking because this token is sent
> out without authenticating the client whereas exchange of code to tokens can
>
On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav wrote:
> But that's just an annoying implementation detail.
Yes. The user-agent flow is a set of annoying implementation details
that are very, very useful if you want to make the protocol efficient.
> If the only different now between the hybr
On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav wrote:
> The exact same argument can be made that the hybrid flow meets all the use
> cases of the web-server flow... which means we can keep the current single
> flow specification as is... :-)
>
> What am I missing? (I'm asking).
The hybrid
On Mon, Jan 10, 2011 at 3:42 PM, Eran Hammer-Lahav wrote:
> These are two very different client profiles. In one, the client is
> completely authenticated, residing solely in the user-agent. The other is a
> mix authenticated and unauthenticated, where parts of the client can keep a
> secrets b
On Mon, Jan 10, 2011 at 3:22 PM, Phil Hunt wrote:
> What about the idea that the code is only used as a hand-off mechanism
> between service components (e.g. authorization manager vs, resource access
> manager). In that case, the code would not be usable for anything except to
> get an access
On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav wrote:
> What about the difference between the two access tokens? The one issued
> directly and the one via the code? Are those the same? Same scope? Same
> duration?
Same.
> I think this needs to be presented as a separate profile from the us
On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav wrote:
> This explains why you want the code returned in the fragment, but not why you
> need both code and token in the same response, as well as any differences in
> the token attributes,
The token in the same response is a latency optimizati
On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav wrote:
> In -12, I am moving back to the -05 specification structure of profiles
> (flows).
Sweet!
> This means this code_and_token hybrid needs to be explained beyond
> just the definition of the extra parameter and response format. But I don’t
On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones
wrote:
> I am willing to serve as editor for the bearer token specification and have my
> management's approval to do so. Furthermore, I believe that I am qualified,
> having successfully served as an editor for several standards specifications,
> incl
Hey Aaron -
Here's some more research and recommendations for you:
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html.
I agree with the other recommendations on this thread, probably not a
good idea for you to invent a hashing scheme for
On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote:
>> The other reason people get funny with these status codes has to do
>> with browser behavior. Sometimes browsers react in funny ways to
>> funny HTTP status codes. To be on the safe side, developers tend to
>> return an HTTP 200 with wh
On Tue, Aug 17, 2010 at 7:33 PM, John Panzer wrote:
> Is there any legit reason other than jsonp specifically?
Protected resource authors are slack and are not going to read the
spec. That might not be a great reason, but it's not a bad one
either.
The other reason people get funny with these s
On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wrote:
> Luke's point still holds true of the core spec needing to allow a 200 status
> code on an error in this scenario. I'd also rather see this as part of the
> core spec as it reduces the number of things that implementors will need to
> read f
On Thu, Aug 12, 2010 at 12:36 PM, David Recordon wrote:
> I've only been half following the recent assertion threads for this
> exact reason. I don't understand how these proposals are going to be
> used and worry about any additional complexity added to the spec.
Likewise.
__
of the flow is for third-party.com to access printing.com. That is
what the user wants to have happen, and the service provider wants to allow
it.
Cheers,
Brian
On Thu, Aug 12, 2010 at 8:26 AM, Oleg Gryb wrote:
>
>
>
>
> - Original Message
> > From: Brian Eato
On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote:
> The thing is that each time when a web app with sensitive info can be run in
> a frame, security people would advice to break that
> frame-reads-other-frame-data logic, because it can lead to violation of same
> origin policy.
This is incorrect
On Wed, Aug 4, 2010 at 10:04 AM, Torsten Lodderstedt
wrote:
>> So far no one has offered to work on the security consideration section
>> (Brian's draft is too far from the format I need to incorporate).
>>
>
> I could work on this topic, if Brian does not insist to do so.
> @Brian: What do you th
On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote:
> thirdparty.com never gets the access token in the scenario that Brian has
> described, becuase fragment that was sent by a service provider in Location
> header is not going to travel to the thirdparty.com server.
This is not quite true.
thirdpa
On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote:
> So if the browser works correctly (instead of what the python library does,
> then thirdparty.com sees only "GET rpc_relay.html", while the javascript
> also gets the "access_token=12345".
In the average case, thirdparty.com doesn't even see GET
gt;
>> On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote:
>>
>>> On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote:
>>>>
>>>> On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote:
>>>>
>>>> Please provide an example of code that you wou
On Tue, Aug 3, 2010 at 9:59 AM, Oleg Gryb wrote:
>> Question: why are you implementing the user-agent flow?
>
> It's not helpful. Doesn't answer the qs.
The reason I asked is because I suspect you are trying to use the
user-agent flow in a way very different from other people.
It's important to
On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb wrote:
> Returning to our discussion about necessity of passing access_token in URL's
> fragment, I've read both your proposal for changing v.9 and the current
> v.10, but still don't understand why we need access_token in a fragment.
Question: why are
On Mon, Aug 2, 2010 at 6:15 PM, David Stanek wrote:
> I just verified that the Python urllib client does send the fragment to the
> server. I've created a patch and will be created a bug on the Python
> tracker.
>
Cool, but this doesn't seem relevant to the user-agent profile. Market
penetratio
On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb wrote:
>
> What about browsing history? I've just run the JSP below in Tomcat and found
> out that Firefox remembers the redirect in the browsing history. It'll be a
> problem in a shared desktop or Internet kiosk environment.
I think the best practice
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
wrote:
> There seem to be two potential arguments against it - the burden of
> tracking the state and the potential that it's unnecessarily
> restrictive. I don't personally see either as being a major issue but
> would like to hear from folks if t
On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav wrote:
> How do you link the client_id using in the authorization endpoint with the
> client assertion using in the token endpoint?
In theory:
"any document that defines how to use an assertion of a particular
type with OAuth 2.0 MUST define ho
On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav wrote:
> I understand that in many assertions, the client identifier is established
> internally, but this approach will completely prevent using the assertion
> client authentication method with other flows that involve getting a code.
I'm prett
with all the other grant types.
>
> -- Justin
>
> On Sat, 2010-07-17 at 15:51 -0400, 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.
>>
>> EHL
>>
>>
On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard wrote:
> As far as consistency, it is just a little weird to call it "client password"
> in one
> part of the spec, when it's defined as "client secret" elsewhere.
Agreed, we could be more consistent. The value we're talking about is
the same in all
On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav wrote:
> The use case is pretty simple: the user uses the server and approves a third
> party site access to their data directly (i.e. They are not sent to the
> server from the client, but just use the server). The third part then uses
> their c
On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav wrote:
> The client authentication can be used to retrieve a grant previously arranged.
Really?
Who is going to implement that?
I'm pretty sure that if the only inputs to the protocol are a client
name and a client password, the output is going
inted. =)
(David, no offense, I'm just trying to stick by my guns on the whole
"stop screwing up the spec by merging separate use cases into single
flows" thing...)
On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav wrote:
> And that matters how?
>
> EHL
>
>
>
> On Jul
On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav wrote:
> External, out-of-band, implicit.
>
> It cannot be client because that is not always the case.
Can you point to a use case where someone is going to use the client
password flow to authenticate something besides a client?
Because I'm pre
1 - 100 of 266 matches
Mail list logo
