Re: [OAUTH-WG] proposal for signatures

Can we get an updated document based on the feedback received? EHL On 6/21/10 12:04 AM, "Dirk Balfanz" wrote: Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures

Re: [OAUTH-WG] assertion profile changes

BTW, I'm not opposed to writing more detailed profiles based on the generic framework provided by the two endpoints defined and theyr many optional components. I think the new format helps clarify the overall architecture and easier to implement a generic client for (given that all the parameter

Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication

Hi, I just wanted to follow up and see if I could solicit a bit more feedback on this request, since it sounds like the end of the OAuth 2 spec is growing near and I would like to see something added to resolve this problem if at all feasible (or suggestions on how else to deal with it; mayb

Re: [OAUTH-WG] assertion profile changes

Use-case: When establishing web federation with customers we allow them to either use their salesforce username ( enforced to be globally unique ) or a federationid ( enforced to be unique to that particular customer/tenant ) as the subject of their SAML assertion. Since our SAML ACS is global

Re: [OAUTH-WG] assertion profile changes

On Wed, Jul 7, 2010 at 4:51 PM, Chuck Mortimore wrote: > This thread forced a great deal on internal discussion today, and we > actually do have some more immediate use-cases where we'll require > client_id with the assertion flow > > I support leaving it as optional Can you describe the addition

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

On Wed, Jul 7, 2010 at 1:11 PM, Eran Hammer-Lahav wrote: > Thanks. Browser security is not my area. > > It seems to me that this must be documented as all the examples I have seen > for such scripts did not include any such security measures. Nor is it mine. I know some techniques for cross-orig

Re: [OAUTH-WG] assertion profile changes

This thread forced a great deal on internal discussion today, and we actually do have some more immediate use-cases where we'll require client_id with the assertion flow I support leaving it as optional -cmort On Wednesday, July 7, 2010, Brian Eaton wrote: > On Wed, Jul 7, 2010 at 2:52 PM, Eran

Re: [OAUTH-WG] assertion profile changes

On 7/7/10 3:01 PM, "Brian Eaton" wrote: On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be usef

Re: [OAUTH-WG] assertion profile changes

On Wed, Jul 7, 2010 at 2:52 PM, Eran Hammer-Lahav wrote: > I disagree with this approach. There are plenty of optional parameters in > the spec. Yes. I think most of them are a bad idea. > The assertion access grant requires further profiling to be useful. This > doesn’t mean it needs another s

Re: [OAUTH-WG] assertion profile changes

I disagree with this approach. There are plenty of optional parameters in the spec. The assertion access grant requires further profiling to be useful. This doesn't mean it needs another spec, but that when you use it, you need to document clearly what is expected. When you do that, spell out w

Re: [OAUTH-WG] assertion profile changes

On Wed, Jul 7, 2010 at 2:18 PM, Eran Hammer-Lahav wrote: > On 7/7/10 2:02 PM, "Brian Eaton" wrote: >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? > > This was requested a few months ago and was included in -05 as optional. I > did not see any f

Re: [OAUTH-WG] assertion profile changes

I'm currently finishing an extension spec for client-to-client access delegation based on the assertion profile. I believe it will use the client secret and return a refresh token, because the assertion is meant to be temporary, at least in its current form. If the assertions are moving in a

Re: [OAUTH-WG] assertion profile changes

I don't have time to go dig through the list archive. On 7/7/10 2:02 PM, "Brian Eaton" wrote: > On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav wrote: >> It is pretty much the same as originally proposed. Any recent changes are an >> oversight, not any intentional change. Since it was propos

Re: [OAUTH-WG] assertion profile changes

On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav wrote: > It is pretty much the same as originally proposed. Any recent changes are an > oversight, not any intentional change. Since it was proposed, the only > change made (with full consensus) was to allow client authentication as an > optional r

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

I think this squarely belongs in the Security Consideration section! In fact, I think that all other items there ought to be written using the same template: a) Problem, b) Solution(s) along with pros and cons. Igor Eran Hammer-Lahav wrote: Thanks. Browser security is not my area. It seems

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

Thanks. Browser security is not my area. It seems to me that this must be documented as all the examples I have seen for such scripts did not include any such security measures. EHL On 7/7/10 1:06 PM, "m...@automattic.com" wrote: On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav wrote: > T

Re: [OAUTH-WG] assertion profile changes

On 7/7/10 9:40 AM, "Brian Eaton" wrote: > Hi folks - > > What is the story with the evolution of the assertion profile? It is pretty much the same as originally proposed. Any recent changes are an oversight, not any intentional change. Since it was proposed, the only change made (with full c

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav wrote: > The issue is that it is hard (or even impossible) to prevent another > user-agent client from imitating another user-agent client. A pre-registered > redirection URI does very little to help. In most cases, such a URI will > point to a we

Re: [OAUTH-WG] Security of user agent clients (WAS: End user authresponse code-and-token's scope parameter)

The issue is that it is hard (or even impossible) to prevent another user-agent client from imitating another user-agent client. A pre-registered redirection URI does very little to help. In most cases, such a URI will point to a web page with a script that will extract the information and pass

Re: [OAUTH-WG] register prefixes as opposed to full parameter names

On Wed, Jul 7, 2010 at 10:31 AM, Marius Scurtescu wrote: > On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams wrote: >> Actually, for a small minority of WordPress sites wanting to enable >> OAuth (those not supporting so called "pretty permalinks"), the >> WordPress plugin would need to internally

Re: [OAUTH-WG] assertion profile changes

Good catch Brian - client_id and client_secret now seem mandatory when reading draft 9. When those were originally added to the flow, they were clearly marked as optional. That is lost in the latest drafts. We'd be happy with either optional or removed. Mandatory doesn't work for us at al

Re: [OAUTH-WG] register prefixes as opposed to full parameter names

On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams wrote: > On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams wrote: >> WordPress uses query parameters.  A WordPress plugin that enables >> OAuth, though, would have to register new URL handlers with WordPress >> to act as the token and end-user author

[OAUTH-WG] assertion profile changes

Hi folks - What is the story with the evolution of the assertion profile? As far as I can tell, it keeps changing for no good reason. Everyone who wants to implement the profile has the exact same requirements, and agreed on how it should work a long time ago. Here's the timeline: - a bunch of

Re: [OAUTH-WG] Draft 9, Section 4.1.1 missing several parameters

+1 on reference to section 2. Also, in 4.1.1, the wording in the last paragraph makes it sound like the client_secret is REQUIRED for flows using the authorization code, when as per section 2 the secret is only required IF a secret was issued with the client_id. Wording such as found in 4.1.2 is a

Re: [OAUTH-WG] register prefixes as opposed to full parameter names

On Wed, Jul 7, 2010 at 12:57 AM, Michael D Adams wrote: > WordPress uses query parameters.  A WordPress plugin that enables > OAuth, though, would have to register new URL handlers with WordPress > to act as the token and end-user authorization endpoints.  Having done > so, the plugin would then h

Re: [OAUTH-WG] register prefixes as opposed to full parameter names

On Tue, Jul 6, 2010 at 10:24 PM, Marius Scurtescu wrote: > On Tue, Jul 6, 2010 at 10:18 PM, Michael D Adams wrote: >> For section 6.2 (query parameters on the end-user authorization and >> token endpoints), this should not be an issue for WordPress. >> >> For section 6.3 (header parameters), this

Re: [OAUTH-WG] [oauth] Enterprise usage question: Role based access and scope parameter

"scope" is about the permissions that a client application is requesting. But if those permissions are inherently bound to the users becaus the users have certain roles, the Access Token requested for a user can be bound to those roles by the Authorization server. I don't feel there's a requirement