[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