[Code] Code Digest, Vol 11, Issue 9

Fri Feb 12 12:42:39 UTC 2010

code no

2010/2/12, openid-code-request at lists.openid.net
<openid-code-request at lists.openid.net>:
> Send Code mailing list submissions to
> 	openid-code at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.openid.net/mailman/listinfo/openid-code
> or, via email, send a message with subject or body 'help' to
> 	openid-code-request at lists.openid.net
>
> You can reach the person managing the list at
> 	openid-code-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Code digest..."
>
>
> Today's Topics:
>
>    1. Re: OpenId on no HTML user-agents (Jason Young)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Feb 2010 18:16:21 -0500
> From: Jason Young <jason.young at extension.org>
> Subject: Re: [Code] OpenId on no HTML user-agents
> To: openid-code <openid-code at lists.openid.net>
> Message-ID:
> 	<8cb4d9bf1002111516k5d1eb0dehe0795728ed202479 at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> 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-0001.htm>
>
> ------------------------------
>
> _______________________________________________
> Code mailing list
> Code at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-code
>
>
> End of Code Digest, Vol 11, Issue 9
> ***********************************
>