[Code] OpenId on no HTML user-agents

Thu Feb 11 17:42:06 UTC 2010

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/001119.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
>

-- 
Regards,
Hitoshi Uchida <hitoshi.uchida at gmail.com>