http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
Forest <tadafor...@gmail.com> schrieb: Thanks for the clarification. The subtle difference makes sense to me, and indeed was what prompted me to address this list in the first place. It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at it until six sections after a very clear "MUST" statement apparently forbidding this use of client credentials. I nearly walked away from OAuth 2 as soon as I read that bit in Section 4.4, and I suspect others would do exactly that. I only discovered the distinction because I happened to read an additional twelve discouraging pages past the apparent roadblock. So, for the sake of clarity in the working draft and in the hope of widespread adoption, I suggest that this subtle difference be stated alongside aforementioned MUST statement. I'll read the oauth-security rationale. Thanks for the link. I'm having trouble finding the current device flow proposal. The last mention of it I remember was an earlier oauth-v2 draft. Can you send me a current link? Cheers, Forest On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi, > > there is no contradiction. The subtle difference lays in the word > "instance". Using secrets for a software package (and all of its > installations) is useless and therefore not allowed. If you are able to > issue a distinct id/secret pair to every installation of your app, this is > fine. > > For a the complete rationale pls. take a look into > http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. > > The question is whether you really want to authenticate the client or the > user. For users, resource owner password is an option. I agree with you that > the user experience is bad. You may consider to use another device (pc, > smartphone) to perform the authorization flow. You may take a look onto the > device flow proposal. Alternatively, you could utilize the code flow on the > secondary device and ask the user to enter the code on the TV Set. > > regards, > Torsten. > > > > > Forest <tadafor...@gmail.com> schrieb: >> >> Hi there. >> >> I've been considering OAuth 2 and its "client credentials" grant type >> for use with applications that run on televisions and other consumer >> devices. It is appealing mainly because it requires no built-in web >> browser and no cumbersome data entry for the user. (Similar to the >> Netflix device registration procedure.) However, I think I've run >> into a snag. >> >> Section 4.4 of draft-ietf-oauth-v2-22 says: >> "The client credentials grant type MUST only be used by confidential >> clients." >> >> Since Section 2.1 defines confidential clients as distinct from >> "clients executing on the resource owner's device", I have the >> impression that this forbids pretty much any device in the user's >> possession from using client credentials. (Except perhaps the rare >> gadget that embeds encrypted storage and physical safeguards against >> key >> discovery.) I suppose this would mean OAuth 2 is unsuitable for >> the task at hand. >> >> However, Section 10.1 says: >> "The authorization server MAY issue a client password or other >> credentials for a specific installation of a native application client >> on a specific device." >> >> This seems to contradict Section 4.4, although if I understand it >> correctly, it would allow me to use client credentials as I had hoped >> without violating the spec. That's encouraging. Maybe I can use >> OAuth 2 after all, so long as each installed instance of my >> application gets its own credentials. >> >> So, I could use some clarification on a few points: >> >> 1. Is that quote in Section 10.1 meant to be an exception to the one >> in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for >> the exception and to make it easier for OAuth 2 implementors to >> discover. >> >> 2. If it is not intended as an exception, meaning that >> apps running on >> consumer devices are not to be issued client credentials, what is the >> recommended alternative? Section 1.3.3 suggests resource owner >> password credentials when "other authorization grant types are not >> available", and using a "long-lived access token or refresh token". I >> suppose this approach would enable OAuth on devices that have no web >> browser, though it would create a usability problem by requiring users >> to enter their credentials using awkward, frustrating input devices >> (like 5-button remote controls). Perhaps more importantly, it begs >> the question of how storing a long-lived token is any more secure than >> storing client credentials. After all, both could grant access, both >> could be revoked, and both could be exposed just as easily. Which >> brings me to my third question: >> >> 3. From whom is a "confidential" client expected to keep its >> credentials secret? From the resource owner? (I >> suppose this would >> make sense for a server-side application trusted by many users, but it >> makes little sense for a consumer device, since a user is unlikely to >> give out his own device's credentials and could more easily give out >> his own password.) From other applications running on the same >> device? (This makes sense, but devices with sandboxed per-application >> storage would seem to warrant an exception from the "clients executing >> on the resource owner's device" generalization in Section 2.1.) From >> the world at large? (If this is the only level of confidentiality >> then I would think "clients executing on the resource owner's device" >> would easily qualify as confidential.) >> >> Thanks, all. I look forward to a better understanding of what is intended >> here. >>_____________________________________________ >> 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
