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 its own credentials as well.
Wrt storing the user's credentials on the device, we are profiling the
authz code grant type - we don't want passwords on the device , or even
traded via RO creds grant type. But was that the question?
thanks
paul
On 12/19/11 1:21 PM, John Kemp wrote:
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 -
particularly the ability to 'securely' authenticate to the AS on the token endpoint.
Well… from your description of your case (e.g. "based on a user's
subscriptions"), I'm not sure whether the client (software) designation makes much
difference. Am I correct in thinking that the credentials which really need to be
protected are those assigned to a user, rather than those assigned to a client? In which
case, wouldn't it be possible for even a 'public' OAuth client to acquire them from the
user dynamically (rather than storing them on the device) and pass them encrypted or
hashed to the server?
Cheers,
- John
thanks
paul
On 12/19/11 12:18 PM, Michael Thomas wrote:
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. It is for the second
class of clients that I'd appreciate some clarification of 'confidentiality' as
defined in OAuth 2.
OAuth 2 distinguishes confidential& public clients based on their ability to
secure the credentials they'd use to authenticate to an AS - confidential clients
can protect those credentials, public clients can't.
Notwithstanding the above definition, the spec gives a degree of discretion to
the AS
The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure
levels of client credentials.
Give this discretion, is it practical for the OMAP spec to stipulate that 'All
Clients (both server& native mobile), MUST be confidential', ie let each
individual OMAP AS specify its own requirements of clients and their ability to
securely authenticate?
Hi,
Can you say exactly what your security requirements are before trying to
determine which
(if either) is the right answer? I've got some concerns in this area that I'm
trying to understand
and am not sure if they're related to your concern or not. Part of this is that
I really don't
understand what the difference is between a "public" client and a "confidential
client" and
rereading the draft isn't helping me. In particular, can a iPhone app with a
UIWebView *ever*
be a "confidential" client, and if so how?
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
