[Code] OpenId on no HTML user-agents
valentino miazzo
valentino.miazzo at blu-labs.com
Mon Feb 15 08:25:35 UTC 2010
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>
> 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 <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/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 <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> 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/20100215/c5e29b9d/attachment.htm>
More information about the Code
mailing list