Hi Valentino - If you’re trying to get a BD Player to connect to your web services, you’re probably going to need to pass a credential to the device so that it can access your APIs. Unfortunately, OpenID by itself does not solve this use case – you’ll have to use Oauth. However, Oauth requires a browser.
If your device doesn’t have a browser, and you’re expecting your users to authenticate with a username and password, then Oauth-WRAP will probably satisfy your requirements. See Section 5.5 – Username/Password Profile in the WRAP spec for more details. More details about OAuth-WRAP are here: http://groups.google.com/group/oauth-wrap-wg Allen On 2/15/10 12:25 AM, "valentino miazzo" <[email protected]> wrote: > Hi Allen, > maybe you missed my answer to Yang Zhao : > http://lists.openid.net/pipermail/openid-code/2010-February/000088.html > >> > is the use-case that certain browserless devices need a standardized way to >> authenticate a user? > Yes > >> > How is the user expected to authenticate with their identity provider? > Via a java application burned on a blu-ray disc > >> > Do you need to support an infinite number of identity providers, or just a >> few? > I hoped to use OpenId to support an infinite number of IP. > > The main reason to support OpenId is avoid the registration and login steps. > I assume the user has a pre-existing OpenId account created before via HTML > browser. > > Thanks, > Valentino > > > Allen Tom said the following on 13/02/2010 1.10: >> >> [+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]> >> <mailto:[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"; >>>> <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"; >>>> <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]> >>>> <mailto:[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/001 >>>>> 11 >>>>> 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]> >>>>> <mailto:[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]> <mailto:[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
