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
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 keep
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
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
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
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,
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
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
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
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
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
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 -
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 -
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
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
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
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
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
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)
19 matches
Mail list logo
