Re: [OAUTH-WG] Is Allow / disallow screen mandatory ?

What are the security concerns about not having such Allow / disallow screen ? Obtaining access to a user's data without their consent? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Is Allow / disallow screen mandatory ?

On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Jerome, you raise a good and important point. A core part of the OAuth specification is to obtain the consent of the resource owner. If you look at Section 1.3 of

Re: [OAUTH-WG] OAuth 2.0 and Access Control Lists (ACL)

On Sun, Dec 18, 2011 at 12:05 PM, Melvin Carvalho melvincarva...@gmail.comwrote: Quick question. I was wondering if OAuth 2.0 can work with access control lists. For example there is a protected resource (e.g. a photo), and I want to set it up so that a two or more users (for example a

[OAUTH-WG] Secure storage of access for clients of the implicit flow

. -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] best practices for storing access token for implicit clients

refreshes. LocalStorage seemed to fit right but I wasn't sure what holes that may open up since other scripts may have access to the same local storage as the page that intercepts the access token. -Doug Tangren http://lessis.me On Mon, Jul 11, 2011 at 7:08 PM, Ian McKellar i...@mckellar.org wrote

[OAUTH-WG] best practices for storing access token for implicit clients

What is the current recommended practice of storing an implicit client's access_tokens? LocalStorage, im mem and re-request auth on every browser refresh? -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

[OAUTH-WG] best practices for storing access token for implicit clients

What is the current recommended practice of storing an implicit client's access_tokens? LocalStorage, im mem and re-request auth on every browser refresh? -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

Re: [OAUTH-WG] consistency of token param name in bearer token type

-Doug Tangren http://lessis.me Just one question: Is the assumption of the group that bearer tokens are the only type of tokens to be used in conjunction with URI query parameters? Otherwise, a mechanism is needed to distinguish bearer and other tokens, e.g. another parameter (token_type

Re: [OAUTH-WG] consistency of token param name in bearer token type

-Doug Tangren http://lessis.me On Fri, Jun 10, 2011 at 4:20 AM, David Recordon record...@gmail.com wrote: George, Doug and Eran are you alright with the Bearer token spec using the parameter name access_token as well? Consistency is good and less confusing for developers writing generic

Re: [OAUTH-WG] OAuth Interim Meeting: Polished Meeting Notes

Thanks for posting this Hannes -Doug Tangren http://lessis.me On Fri, Jun 3, 2011 at 8:45 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Bill Mills (post-processi ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo

Re: [OAUTH-WG] Text for Native Applications

-Doug Tangren http://lessis.me On Wed, Jun 1, 2011 at 1:39 AM, Kris Selden kris.sel...@gmail.com wrote: Why can't you just revoke the refresh token for a client when you change the client secret? This makes sense for a server implementation for added precaution but in practice, most clients

Re: [OAUTH-WG] Text for Native Applications

-Doug Tangren http://lessis.me For example, a iOS app that is shipped through iTunes certainly has access to reasonably secure storage via KeyChain for secrets issued to the application at runtime, such as the referesh_token, but it can’t do a good job of protecting the client_secret, since

Re: [OAUTH-WG] Text for Native Applications

-Doug Tangren http://lessis.me On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore cmortim...@salesforce.comwrote: 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

Re: [OAUTH-WG] Text for Native Applications

Consider what happens when a client web server is compromised and the client secret and refresh tokens are stolen. - the attacker can use the tokens until the compromise is discovered. - the client secret is then changed - the stolen refresh tokens then become useless Now, *if* the

Re: [OAUTH-WG] Question on action item to make RedirectURI optional

-Doug Tangren http://lessis.me On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: why must the redirect_uri be validated if it is pre-registered and not included in the authorization request? I think the preregistered redirect_uri may only require

Re: [OAUTH-WG] Question on action item to make RedirectURI optional

token request for the returned code, the redirect_uri must be http://foo.com/authed/bar -Doug Tangren http://lessis.me On Sat, May 28, 2011 at 7:44 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: server ___ OAuth mailing list OAuth@ietf.org

Re: [OAUTH-WG] consistency of token param name in bearer token type

-Doug Tangren http://lessis.me On Sat, May 28, 2011 at 12:30 PM, David Recordon record...@gmail.comwrote: Did a full read through of draft 16 and the bear token spec with Paul yesterday afternoon in order to do a manual diff from draft 10. The point Doug raised was actually confusing

[OAUTH-WG] draft 16 notes on security considerations

/draft-ietf-oauth-v2-16#section-10.9 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] See everyone in the morning

For those joining remotely does the meeting actually start @ 9 or 10. I looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's my lunch time. -Doug Tangren http://lessis.me On Sun, May 22, 2011 at 1:40 PM, David Recordon record...@gmail.com wrote: If you're planning

Re: [OAUTH-WG] See everyone in the morning

ok. I'll going to run for lunch and sneak quietly in on the conf call ~ 10 (1 for me). -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 12:22 PM, Brian Campbell bcampb...@pingidentity.com wrote: Looks like they are starting now. On Mon, May 23, 2011 at 9:35 AM, Doug Tangren d.tang

Re: [OAUTH-WG] See everyone in the morning

-Doug Tangren http://lessis.me On Mon, May 23, 2011 at 12:24 PM, Doug Tangren d.tang...@gmail.com wrote: ok. I'll going to run for lunch and sneak quietly in on the conf call ~ 10 (1 for me). -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 12:22 PM, Brian Campbell bcampb

Re: [OAUTH-WG] See everyone in the morning

Thanks It would be nice to have in http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-6 -Doug Tangren http://lessis.me On Mon, May 23, 2011 at 1:47 PM, Marius Scurtescu mscurte...@google.comwrote: On Mon, May 23, 2011 at 10:29 AM, Doug Tangren d.tang...@gmail.com wrote: Im on skype

Re: [OAUTH-WG] Draft -16

]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2 [7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] purpose of client sending bodyhash in mac authorized requests

calculation. That would be one less header field server implementors have to handle different paths of executions for. [1]: https://github.com/n8han/unfiltered/#readme [2]: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05#section-4 -Doug Tangren http://lessis.me

Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0

-Doug Tangren http://lessis.me On Fri, May 13, 2011 at 12:58 PM, Francisco Corella fcore...@pomcor.comwrote: We wrote a security analysis of double redirection protocols that has a section on OAuth 2.0 as of draft 11. You can find it at http://pomcor.com/techreports/DoubleRedirection.pdf

Re: [OAUTH-WG] OAuth Interim Meeting

2 questions? 1. Would there be a conference line one could dial into remotely? (I'm in New York City) 2. Is this open to implementors of the spec in addition to it's authors? (I'm currently implementing draft 15 as developer @ meetup.com) -Doug Tangren http://lessis.me

Re: [OAUTH-WG] OAuth Interim Meeting

Thanks guys. Added my name to the list. -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] consistency of token param name in bearer token type

be used in other protocols without being confused with oauth2 access_tokens? [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 -Doug Tangren http://lessis.me

[OAUTH-WG] oauth2 implicit flow user experience

for the refreshing of an access token in an implicit flow. Has there been any conversation around possible alternatives that would permit users of the implicit flow to have the same user experience as the authorization code flow? Thanks -Doug Tangren http://lessis.me

[OAUTH-WG] requirement of redirect_uri in access token requests

links back to section 3.1 which does use a redirect_uri in the example. Should the redirect_uri be a requirement for client authentication or is it optional? -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

[OAUTH-WG] implicit clients and refresh tokens

that can't securely secure a client secret like a web browser. Is providing no way for an implicit client to refresh an access token without involving the resource owner intended? -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https

Re: [OAUTH-WG] implicit clients and refresh tokens

an understand the danger is in this if an access token were leaked so I am making sure to implement expiring tokens. I just wasn't sure if this was in the cards for clients implementing an implicit flow. Thanks for responding so quickly guys. -Doug Tangren http://lessis.me