[+sp...@openid] Hi All -
I missed some of the context here - is the use-case that certain browserless devices need a standardized way to authenticate a user? How is the user expected to authenticate with their identity provider? Do you need to support an infinite number of identity providers, or just a few? At least in my experience, most of these specialized devices only need to authenticate with a single identity provider. For example, Yahoo has partnered with many HDTV manufacturers to let Yahoo users use their Yahoo account on the TV set. In this case, we use a proprietary protocol that is nearly identical to the "Username/Password Profile" defined in Section 5.3 of the WRAP-0.9.7.2 spec. It's also pretty much equivalent to Google's Client Login interface. In both cases, the client asks the user for their username/password, and the client validates the username/password with the authentication server. If that's what you want, then I suggest reading the Oauth-WRAP spec. More details here: http://groups.google.com/group/oauth-wrap-wg Hope that helps, Allen On 2/11/10 10:04 AM, "valentino miazzo" <[email protected]> wrote: > Hi Hitoshi, > > I agree. > More in general, this mechanism can be used to avoid to hard-code in the > spec of the extension some constants. > > There are millions of connected BD players and HDTVs not able to parse HTML. > The owners of these devices would find in the proposed extension another > good reason to obtain an OpenID. > > Thanks, > Valentino > > Hitoshi Uchida said the following on 11/02/2010 18.42: >> Hi Valentino, >> >> I'm also would like OpenID/OAuth WG to consider the embedded devices >> usecase which don't have a web browser. >> >> I understand your consideration that definition of POST URLs to be >> used for submit and trust operation is helpful for those embedded >> devices. >> However, I think it wouldn't be good solution to define the path of >> URL like '/signin_submit' or '/trust_submit' as spec. >> >> So my idea is that a below tag should be contained in the HEAD section >> of the HTML loggin page sent by OP like OpenID HTML discovery. >> <link rel="openid2.provider.signin openid.server.signin" >> href="https://www.myopenid.com/signin_submit"/> >> >> Then, for instance, 'signin_id' and 'signin_password' parameters >> representing user's account information would be sent against the URL. >> >> And a below tag would be contained in the trust/deny HTML page sent >> after the user's authentication. >> <link rel="openid2.provider.trust openid.server.trust" >> href="https://www.myopenid.com/trust_submit"/> >> >> Those simple tag can be parsed easily by embedded devices. >> And also, such an additional link tag of HEAD section can keep >> interoperability. >> >> What do you think ? >> >> Best Regards, >> Hitoshi Uchida >> >> >> >> 2010/2/11 valentino miazzo <[email protected]>: >> >>> Chris, did you have a chance to read my answer? >>> Does anyone has something to add? >>> >>> Thanks >>> Valentino >>> >>> PS: Added Allen Tom and Hitoshi Uchida. They were discussing something >>> similar in openid-user-experience ML. >>> http://lists.openid.net/pipermail/openid-user-experience/2010-February/00111 >>> 9.html >>> >>> valentino miazzo said the following on 05/02/2010 10.34: >>> >>> Hi Chris, >>> with the name proposal I wanted to be funny but maybe I seemed not humble. >>> Sorry for this. >>> >>> I will try to be more clear about my proposal. >>> Basically I see a low hanging fruit but, being a newbie with OpenId, maybe I >>> overlook something. >>> >>> As explained to Yang Zhao in another post I assume the user has a valid >>> OpenId. >>> I just want to be able to use such OpenId from limited devices. >>> It's OK that the user used an HTML browser to create his account. >>> >>> In my understanding of the OpenId user experience, the user interacts with >>> OP HTML pages in at least 2 scenarios (as told, I intentionally exclude >>> OpenId account creation): >>> 1) the OpenId session is closed/expired and the user needs to login in his >>> OpenId account with a one factor authentication. >>> 2) a RP not in the trust list requested user authentication and the user is >>> asked to trust it or deny. Plus the user can choose to add/remove the RP >>> to/from the trust list. >>> >>> For sure, an OP can add more features (2 factors authentications, Oauth, >>> etc...) but this seems the minimal possible interaction with the OP HTML >>> pages. >>> The involved OP HTML pages eventually send a POST request to an URL that >>> actually perform the login and trust management. >>> My proposal is add an extension to the specifications that dictates how >>> these 2 POST requests must be made. >>> As concrete example, if MyOpenId decides to adopt this extension then it >>> will change the code handling these 2 URLs >>> https://www.myopenid.com/signin_submit , >>> https://www.myopenid.com/trust_submit to cope with the extension >>> specifications. >>> >>> Why do that? Because, in this way, user-agents not supporting HTML could >>> just ignore the HTML pages and invoke the POST URLs directly. >>> For users using an HTML browser nothing changes. POST syntax changes are >>> completely invisible to the user. >>> Maybe, OP supplying a richer user experience compared to what I described at >>> point 1 and 2 can offer simplified HTML pages and serve them to limited >>> devices. >>> >>> Point 5 of the protocol overview of OpenId 2.0 specs >>> (http://openid.net/specs/openid-authentication-2_0.html#anchor2) says: >>> <<5. The OP establishes whether the end user is authorized to perform OpenID >>> Authentication and wishes to do so. The manner in which the end user >>> authenticates to their OP and any policies surrounding such authentication >>> is out of scope for this document. >> >>> So, the proposed extension doesn't overlaps in any way with the OpenId specs >>> because this part was intentionally not part of the OpenId standard. >>> >>> I tried, but I'm not able to found how this extension could change the >>> existing security model of OpenId. >>> >>> I'm very interested in knowing your (and others) opinion. >>> >>> Thank you, >>> Valentino >>> >>> >>> >>> Chris Messina said the following on 04/02/2010 18.20: >>> >>> It's unclear what kind of alternative you're proposing, Valentino. >>> At some point, the user must interact with his/her IDP in order to validate >>> the request without a web browser involved, you'll have to figure out some >>> way to interact with each IDP individually, which would likely require you >>> to pre-register your client device with the IDP so that they can gauge >>> whether to trust the request or not. Even still, that defeats the security >>> model of OpenID. >>> We've been down this path several times in the past several years and the >>> result was OAuth. >>> While it may seem inelegant to have the user interact with a secondary >>> browser-enabled device to authorize access to their account, we've yet to >>> come up with a scalable, universal solution that is also secure. >>> You may have name for your solution, but how would it work technically? What >>> would the user experience be like? And how would it keep the user safe? >>> Curious to hear your proposal. >>> Chris >>> >>> On Thu, Feb 4, 2010 at 9:18 AM, Andrew Arnott <[email protected]> >>> wrote: >>> >>>> Well, OAuth WRAP partially solves the problem because the protocol >>>> actually has a profile that doesn't require a web browser. It requires >>>> that >>>> the client app collect the username+password of the user, which it then >>>> forwards to the service provider in exchange for the WRAP token. >>>> The downsides of this approach is that it depends on the user having a >>>> username+password to begin with (which if it's a pure OpenID account, or >>>> Infocard, etc. there won't be one) and it requires the user to disclose the >>>> password to a third party. >>>> -- >>>> Andrew Arnott >>>> "I [may] not agree with what you have to say, but I'll defend to the death >>>> your right to say it." - S. G. Tallentyre >>>> >>>> >>>> On Thu, Feb 4, 2010 at 6:10 AM, valentino miazzo >>>> <[email protected]> wrote: >>>> >>>>> Andrew Arnott said the following on 04/02/2010 14.48: >>>>> >>>>>> You're correct, Valentino. In OAuth, a device without a web browser on >>>>>> it must indicate to the user to find a web browser [on another device] >>>>>> to authorize the token. >>>>>> >>>>>> >>>>> Ask to a user in the sofa (watching a bluray movie) to find a web >>>>> browser to login and then go back is not an option. Nobody will do it. >>>>> So, it seems Oauth has the same limits of OpenId from this point of view. >>>>> >>>>> Returning to solution C ... in the opinion of you, experts and founders >>>>> of OpenId and Oauth, there is any chance that a some point OpenId >>>>> Providers will converge on a common "submit API" ? >>>>> I have already the name: Embedded OpenId >>>>> :) >>>>> >>>>> Thanks. >>>>> Valentino >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Chris Messina >>> Open Web Advocate, Google >>> >>> Personal: http://factoryjoe.com >>> Follow me on Twitter: http://twitter.com/chrismessina >>> >>> This email is: [ ] shareable [X] ask first [ ] private >>> >>> >> >> >> _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
