[Code] OpenId on no HTML user-agents
Allen Tom
atom at yahoo-inc.com
Wed Feb 17 06:56:44 UTC 2010
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" <valentino.miazzo at blu-labs.com>
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:
>>
>> [+specs at 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" <valentino.miazzo at blu-labs.com>
>> <mailto:valentino.miazzo at blu-labs.com>
>> 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 <valentino.miazzo at blu-labs.com>
>>>> <mailto:valentino.miazzo at blu-labs.com> :
>>>>
>>>>
>>>>
>>>>>
>>>>> 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 <andrewarnott at gmail.com>
>>>>> <mailto:andrewarnott at gmail.com>
>>>>> 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
>>>>>> <valentino.miazzo at blu-labs.com> <mailto:valentino.miazzo at blu-labs.com>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-code/attachments/20100216/f9c38534/attachment-0001.htm>
More information about the Code
mailing list