[Code] OpenId on no HTML user-agents

Thu Feb 11 23:16:21 UTC 2010

Hi all,

I absolutely *do not* want the OpenID Working Group to consider this at all
(not that I think they will).

As a developer, I understand it the desire. being about to have the device
consumer login to their Google/Yahoo/etc. account and use that to access
other services sounds great.

But OpenID isn't about us, it's about a user-centric identity.

Proxy prompting for a username/password that we'd use to authenticate on
their behalf for OpenID is just ludicrous.  It's just the wrong thing to do.
 Some of the OpenID Identity Providers may not use passwords at all.  They
might use multi-factor authentication methods.  As a relying party, I don't
care what they use.  We have some responsibilities as developers to uphold
the values of the protocols we use.  Proxy passwords in an app labeled
"OpenID enabled" subverts those values.

Write the two sides to this.  The web application that does OAuth that lets
the user control what information to share - and have your BluRay app talk
to your own web services.  You'd end up getting a lot more benefits to user
tracking, settings storage, profiling, feature updates, and a thousand other
benefits offloading part of that app to the web anyway.

Jason

On Thu, Feb 11, 2010 at 1:04 PM, 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/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
> >>
> >>
> >
> >
> >
> _______________________________________________
> Code mailing list
> Code at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-code
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason Young --  Engineering Manager, eXtension
http://about.extension.org/wiki/Jason_Young
______________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-code/attachments/20100211/a03b697d/attachment.htm>