[OAUTH-WG] Clock synchronization (was RE: Fwd: issues with token age element - MAC token)

>No window will be big enough as experience shows some users have [clocks] that >are off by more than an hour and a half. FWIW, I have seen users with clocks a year off (not at HP). They set their clocks wrong so they could run expired beta software. Any requirement for synchronizing clocks

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

The issues around redirect_uri seem muddled to me. Here's what I know right now: Brian Eaton apparently said: >This provides a defense against authorization codes which have leaked due to >open redirectors. I looked for "redirector" in http://tools.ietf.org/html//draft-lodderstedt-oauth-se

Re: [OAUTH-WG] Can you use POST to access protected resources?

e comfortable with our present code than I was before. Thanks for the clarification. -Original Message- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Monday, April 18, 2011 4:30 PM To: Freeman, Tim; oauth@ietf.org Subject: RE: Can you use POST to access protected resources? I&

[OAUTH-WG] Can you use POST to access protected resources?

Section 7 of http://tools.ietf.org/html/draft-ietf-oauth-v2-15 gives examples of how to access protected resources. All of the examples use GET. Our protected resources are identified by a query, which might be a few kilobytes. I'm concerned that this may not fit inside the length limitation o

[OAUTH-WG] Is an unguessable client state a security consideration? (was RE: What's up with the secuity considerations? (was RE: Preview of -14))

Home: (408) 774-1298 Cell: (408) 348-7536 -Original Message- From: Barry Leiba [mailto:barryleiba.mailing.li...@gmail.com] Sent: Monday, March 28, 2011 1:19 AM To: Peter Saint-Andre Cc: Freeman, Tim; OAuth WG Subject: Re: [OAUTH-WG] What's up with the secuity considerations? (was RE:

[OAUTH-WG] pre-registered not relevant; figure 3 step E (was RE: Feedback on draft-ieft-oauth-v2-13.txt)

Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, March 25, 2011 12:35 PM To: Freeman, Tim; oauth@ietf.org Subject: RE: Feedback on draft-ieft-oa

[OAUTH-WG] What's up with the secuity considerations? (was RE: Preview of -14)

What's the plan for filling in the security considerations? In the draft below I see: >9. Security Considerations > > [[ TBD ]] Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 From: oauth-boun...@ie

Re: [OAUTH-WG] Feedback on draft-ieft-oauth-v2-13.txt

t's consistent with those components that were registered? The security works better if you do the former, but I'm not aware that the spec says that anywhere. Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -Origin

[OAUTH-WG] Protocol breaks if states are guessable (or redirect uri is guessable and not checked at end) (was RE: Why give the redirect URI when trading an [authorization] code for an access token?)

gers mean, then the protocol is insecure and the spec is broken. The scenario for losing is below, but first I want to give credit to Torsten since I'm basically agreeing with him: (Beginning of the scenario where we can lose if the redirect_uri is guessable) From: Freeman, Tim [mailto:ti

[OAUTH-WG] Feedback on draft-ieft-oauth-v2-13.txt

Hi, I've been out of this for a while working on something else. To get back in, I read through the latest draft and have some feedback. The fact that I've been paying attention to other things for a while means my feedback has a different slant from that of people who have been engaged. On the

[OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

On the face of it, it seems that discussion of whether and how to split the document has derailed collection of use cases. If we had consensus on a list of use cases, that would mean we have identified the problems we're trying to solve. This would still allow slimy political manipulation of t

Re: [OAUTH-WG] Signatures...what are we trying to solve?

From: Prateek Mishra >But as far as signing the request for a protected resource (signature over >access token, client_id, scope, URL, request body) - isn't this requirement >is a simple consequence of network architecture wherein an SSL connection >may terminate quite early at the resource server

[OAUTH-WG] Signatures don't solve that problem (was RE: Signatures...what are we trying to solve?)

Putting the use cases on the table is good because it makes things much clearer. Unfortunately, it's clear that this use case does not work. I'd like to number the steps under "Requirements" so I can refer to them unambiguously: 1. The application at www.sleepwell.example.com

Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?

From: Eran Hammer-Lahav >* If HTTPS is to remain optional for protected resource requests, a >signature-based alternative is required. I agree. If we're going to have signatures for this reason, we should have at least one use case on Zeltsan's use case list (https://datatracker.ietf.org/doc/d

Re: [OAUTH-WG] Why give the redirect URI when trading an [authorization] code for an access token?

ver them, and errors in the use cases can be discovered and fixed rather than being made repeatedly by each person rediscovering the use case. Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -Original Message- From: Eran

[OAUTH-WG] Why give the redirect URI when trading an access code for an access token?

Hi. I'm new here. I searched the archives a bit and didn't immediately find an answer to my question below. My apologies if there was some previous discussion of this that I missed. Looking at the draft spec at http://tools.ietf.org/html/draft-ietf-oauth-v2-10, I see in section 4.1.1 "Author