Re: [OAUTH-WG] conflict: error response invalid_request and state parameter duplication

I see that. But how the server should respond on incorrect request (when it’s not possible to determine correct state to be passed). Specifically, what state should be passed to the client – no one, any or all of them? -- Best regards, Alexey Skolyarov Dino Systems Java Team Phone: +7 (812) 740-

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

If you check out the recording of the UMA webinar from last week, you'll see a demo (starting at about the 33:00 mark) that shows individual user data being accessed according to ACL-type authorization policy settings, with the resource owner able to set these policies and then not have to be on

Re: [OAUTH-WG] Native clients & 'confidentiality'

thanks John, inline On 12/19/11 3:20 PM, John Kemp wrote: Hey Paul, On Dec 19, 2011, at 2:49 PM, Paul Madsen wrote: Hi John, the user identity& credentials are definitely fundamental (they allow the video content to be personalized), but given the valuable nature of the resources being acc

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hey Paul, On Dec 19, 2011, at 2:49 PM, Paul Madsen wrote: > Hi John, the user identity & credentials are definitely fundamental (they > allow the video content to be personalized), but given the valuable nature of > the resources being accessed, many Resource Owners (that produce the video > c

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi George, inline thanks paul On 12/19/11 2:10 PM, George Fletcher wrote: Hi Paul, Is the need to authenticate the client a need to ensure that the content is only displayed on certain devices/clients? Or prevent phishing/stealing of authz bearer tokens? I'm not best qualified to answer but

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi John, the user identity & credentials are definitely fundamental (they allow the video content to be personalized), but given the valuable nature of the resources being accessed, many Resource Owners (that produce the video content) will expect that the clients be able to authenticate with i

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi Paul, On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote: > Hi Mike, to some extent I think my question is not about specific security > characteristics, but rather whether its realistic for our group to mandate > that both server & native clients have the *same* security characteristics - > p

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi Paul, On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote: > Hi Mike, to some extent I think my question is not about specific security > characteristics, but rather whether its realistic for our group to mandate > that both server & native clients have the *same* security characteristics - > p

Re: [OAUTH-WG] Native clients & 'confidentiality'

A part of what George has outlined below is captured in the OpenID Connect Dynamic Registration flow. In that, the Dynamic Registration endpoint MAY be an OAuth2 protected resource. If you could mint your distributed clients with unique identifiers of some type, they could use those as bearer t

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi Paul, Is the need to authenticate the client a need to ensure that the content is only displayed on certain devices/clients? Or prevent phishing/stealing of authz bearer tokens? As you point out, it's possible to protect the bearer tokens and associated refresh tokens "via other mitigatin

Re: [OAUTH-WG] Native clients & 'confidentiality'

Not really sure how you came to the conclusion that native mobile clients can't be confidential? As pointed out in section 3.7 of the http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are guidelines that confidential clients should follow, but does not distinguish between nati

Re: [OAUTH-WG] Native clients & 'confidentiality'

On 12/19/2011 10:20 AM, Paul Madsen wrote: our bearer access tokens (JWT formatted) encapsulate a set of content permissions, and serve to authorize the entity presenting them to the corresponding video content. We dont want those tokens falling into the wrong hands, and so want to prevent an

Re: [OAUTH-WG] Native clients & 'confidentiality'

our bearer access tokens (JWT formatted) encapsulate a set of content permissions, and serve to authorize the entity presenting them to the corresponding video content. We dont want those tokens falling into the wrong hands, and so want to prevent an attacker being able to impersonate a valid

Re: [OAUTH-WG] Native clients & 'confidentiality'

Thanks Justin, FWIW, I agree with your analysis Seems to me we have the following breakdown of clients - confidential server clients - confidential native clients (somewhat theoretical at the moment, assumes either 1) a client registration mechanism to deliver credentials post installation, s

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

I would also recommend looking at User-Managed-Access which provides this kind of layer on top of OAuth2. http://kantarainitiative.org/confluence/display/uma/UMA+Explained Thanks, George On 12/18/11 12:05 PM, Melvin Carvalho wrote: Quick question. I was wondering if OAuth 2.0 can work with a

Re: [OAUTH-WG] Native clients & 'confidentiality'

On 12/19/2011 09:50 AM, Paul Madsen wrote: Hi Mike, to some extent I think my question is not about specific security characteristics, but rather whether its realistic for our group to mandate that both server & native clients have the *same* security characteristics - particularly the ability

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

Why do you need OAuth for that?  You can apply the ACL after authentication, OR you can also specifically issue credentials for access to the specific resource, but this is a limited credential rather than applying a per user ACL. From: Melvin Carvalho To: oa

Re: [OAUTH-WG] Native clients & 'confidentiality'

On 12/19/2011 09:44 AM, Justin Richer wrote: Native mobile clients can't really be confidential clients. The distinction between "public" and "confidential" clients is whether or not they can keep deployment-time secrets; which is to say, a client_secret. This is not to say that they can't kee

Re: [OAUTH-WG] Native clients & 'confidentiality'

Hi Mike, to some extent I think my question is not about specific security characteristics, but rather whether its realistic for our group to mandate that both server & native clients have the *same* security characteristics - particularly the ability to 'securely' authenticate to the AS on the

Re: [OAUTH-WG] Native clients & 'confidentiality'

Native mobile clients can't really be confidential clients. The distinction between "public" and "confidential" clients is whether or not they can keep deployment-time secrets; which is to say, a client_secret. This is not to say that they can't keep *any* secrets. In particular those generate

Re: [OAUTH-WG] Native clients & 'confidentiality'

On 12/19/2011 04:19 AM, Paul Madsen wrote: Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case) We want to support both server & native mobile clients.

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

The user authentication and access control to the resources is out of the OAuth scope. The question is how to make a resource (e.g., a photo) accessible by the authorized clients C1,...,Cn. If each client has obtained a user's authorization for the scopes that include the photo, then all client

Re: [OAUTH-WG] conflict: error response invalid_request and state parameter duplication

The spec already says that you can't repeat request parameters on the line like that, so that's an invalid_request error, as described in section 5.2: 5.2. Error Response The authorization server responds with an HTTP 400 (Bad Request) status code and includes the following param

Re: [OAUTH-WG] conflict: error response invalid_request and state parameter duplication

Hello Buhake, Thanks for your answer! It seems I should explain a bit here – I’m not about how to pass the state with multiple values, I’m trying to figure out how the OAuth-2.0-draft-22 – compliant server should respond on duplication of state request parameter. For instance what should be ret

[OAUTH-WG] conflict: error response invalid_request and state parameter duplication

Hello everybody, Since this is my first post on this list, I’ll say few words about whoami: My name is Alexey Skolyarov, I work in Saint-Petersburg, Russia. I’m interested in OAuth2 because I found no v2 providers for Jersey except Spring Security which is much more comp

[OAUTH-WG] Native clients & 'confidentiality'

Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case) We want to support both server & native mobile clients. It is for the second class of clients that

[OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2011-12-19 02:00, Mike Jones wrote: ... ON SPECIFYING ONLY A QUOTED-STRING SERIALIZATION: I understand and agree with your desire to promote code reuse. You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization f

Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

On 2011-12-19 02:01, Mike Jones wrote: Hi Julian, I'm glad to hear that you're not disagreeing with the decision to disallow '\' in certain parameter values. I think that knowing that brings us much closer to resolution on this issue. I think you misunderstood me. I was referring to the val