Re: Proof of Concept: Identity Credentials Login

On 6/10/14 12:21 PM, Manu Sporny wrote:
> On 06/10/2014 08:00 AM, Kingsley Idehen wrote:
>> I've provided a comment on your blog post. At the same time, my
>> history with Wordpress blogs is that comments are 100% guaranteed to
>> make it to the public, for a variety of reasons.
>
> Unfortunately, there's no comment from you in the moderation queue in
> the blog. :( Would your mind reposting it as I'd like to make sure
> people can read your comments. In the meantime, I'll answer them here.
>
>> The World Wide Web is inherently architected to accommodate multiple
>>  ways of providing services driven by Linked Open Data (i.e., open
>> standards based structured data) and HTTP URIs. I don't believe in
>> OpenID vs Persona vs WebID-TLS vs OAuth etc. These authentication
>> protocols can co-exist.
>
> They can co-exist, but the more technologies that we have that do almost
> the same thing, the more complexity there is and greater the burden on
> Web developers and people using the Web.

This isn't a decision you make in a technology spec or fundamental 
architecture. Imagine if that was a deterrent when designing AWWW.

My concern is that we don't compromise infrastructure that inherently 
dexterous. Doing that is guaranteed failure.

We don't know what "Developer Burdens" are for sure.

We don't even know the anyone's burdens are for sure, once the entity in 
question is a cognitive being.

>
>> Issues with your assertions:
>>
>> [1] They are too generic -- dependency of Client Certification
>> Authentication (CCA) isn't a bad thing bearing in mind only a
>> minority of Browser (circa. 2004) have this problem.
>
> The problem is subjective, true. That said, I continue to assert that
> it's a big problem and is the biggest reason WebID+TLS has gone nowhere.

Okay, but I am also demonstrating to you that competitive pressures and 
"opportunity costs" are the keys to getting browser vendors to respond. 
Right now we have IE, Firefox, and Safari working fine, which leaves 
Opera and Chrome.

The top browsers across desktop, notebooks, tablets, palmtops, and 
phones don't have a TLS CCA problem.

> That said, I'm happy to defer whether or not that approach is a viable
> one to the the WebID+TLS proponents. I'm just not interested in slamming
> my head against that particular usability wall (the management of
> client-side certificates) anymore. :)

You don't have too, the market is going to do that for all of us. 
Identity and Privacy issues are the inflection drivers. That are going 
to turn the current social media space on its head, for many obvious 
reasons e.g., dysfunctional business models that are incompatible with 
privacy and identity.


>
>> [2] Too subjective -- "difficult to use for most non-technologists"
>> isn't a defensible position.
>
> Neither is "it's easy to use for most non-technologists". If we had
> enough money, we'd do a thorough set of usability studies.

Not required.

> That said, I
> think it's telling that this problem has existed for over a decade and
> no real research into the area has been performed.

Like most things, there's a time and a place.

SQL RDBMS engines are a joke today re., data driven agility that 
leverages the Web and Internet, but in the late 70's they were a 
practical solution.

Hypercard is unknown to many because it existed before TimBL got his 
hands on a NeXT machine running NeXTStep. At the time, I (like many 
others) didn't have access to Hypercard (which was Mac Classic only) and 
simply fantasized about what would be possible if NextStep was put to 
use in a much more open way.


> I postulate that it's
> because it's obvious to most UX folks that client-side certificates are
> a dead end wrt. security scalability for the general public. 

The folks that take that position, as far as I am concerned, suffer from 
the same misconception i.e., that developers know best, that all 
problems are approached from the perspective of the programming code as 
opposed to the underlying logic that enables us express data in reusable 
form via entity relations.


> I
> understand that you and a number of other WebID+TLS hold the opposite
> position and think things are getting better. Maybe they are.

For me, WebID-TLS is an option for authenticating identity claims based on:

1. HTTP URIs for entity denotation (naming) and connotation (perception)
2. RDF statements for structured data representation
3. Entity Relation Semantics for understanding how entities are related.

>
> I'm just not willing to wait on the browser vendors anymore, and even if
> the usability problem is improved, I still don't think it'll result in a
> solution that's as easy to use as the Identity Credentials stuff.

You don't have to wait. All I am saying is that WebID-TLS and whatever 
you choose can and will co-exist. Mutual inclusion works, its natural to 
the Web i.e., baked into its design.

>
>> The Client Certificate Authentication (CCA) Problem Status:
>>
>> As of the time of writing this reply, the only browsers with this
>> problem i.e, an inability to disconnect and start new TLS sessions
>> are as follows: Chrome and Opera.
>
> That's not the problem. The problem is that a majority of
> non-technologists find the client-side certificate solution to be
> confusing.

No they don't, that's a misconception.

YouID was developed to refute that very line of thinking.

> Additionally, how do you use client-side certificates from a
> device that you don't own?

Excellent question, here's what happens if you are a YouID user:

1. You open a browser on your borrowed device
2. Goto your folder (Google Drive, OneDrive, Dropbox, Box., 
ODS-Briefcase, WebDAV etc.) and open up the pkc#12 file it created
3. Authenticate when challenged by the host in regards to opening the 
secure pkcs#12 file
4. Install your credentials.

1-4 happen using the native UX of any modern OS since they all have 
inbuilt handlers for pkcs#12.

> How do you make sure they expire at the
> correct time?

By default a YouID generated cert will only run for 15 days. And of 
course, you can simply delete it from the device, again via the native 
UX of the host operating system.

Now that you've mentioned it, I'll have YouID add the ability invoke a 
certificate and key removal which in of itself will simply trigger the 
native OS UI for keystore/keychain access etc..

>
>> I don't see how Opera and Chrome can continue to be deficient re. CCA
>>  bearing in mind the current state of implementations from IE,
>> Safari, and Firefox.
>
> ... because the demand for better client-side cert UIs is almost
> non-existent.

Opera and Chrome are laggards. The problem is identity and privacy, 
Safari, Firefox, and IE are already better. Safari is the default 
browser for Mac OS X and iOS. IE is the default browser for Windows and 
Windows Mobile. What's left re., market share?

>
>> End-users do not need programmers thinking or speaking for them.
>
> Except that we do that with every single line of code that we write. :)

Code is no longer just was so called "programmers" write. That's like 
saying: sentences are only constructed by typists :-)

RDF based structured data representation is coding too i.e., information 
is encoded, transmitted, and decoded.

>
> I understand what you're saying, "choice is good", but don't pretend as
> if we don't make a thousand decisions on behalf of end-users every day
> with the UX choices that developers and designers make in their products.

I don't.

I try to provide something that potentially makes them more productive 
without stepping over the boundary of making critical choices for them. 
When I designed YouID I could have hard wired it to Virtuoso or WebDAV 
and LDP, but I didn't. I wanted the end-user to be able to store their 
identity cards wherever, even if that mean implementing all the 
proprietary APIs associated with Google Drive, Dropbox, OneDrive. Box., 
Amazon S3, and soon to be released iCloud Drive.
>
>> That's broken. What end-users need is the ability to control their
>> identity and privacy online via solutions that leverage Web &
>> Internet architecture such that the following are loosely coupled (no
>> 3rd party .com, .org, .cc etc.. in the way):
>
> Sure, agreed. Why do  you think the Identity Credentials stuff places a
> 3rd party in the way?

I don't see how my credentials end up in a place of my choosing e.g., I 
might want to save those credentials to storage provided by Google 
Drive, Dropbox, OneDrive etc..


> You can run your own IdP if you'd like, the code
> is on Github right now and we do plan to release a completely open
> source, public domain implementation of it in time. You don't have to
> use any 3rd party if you don't want to.

That something I (or anyone else) needs to code at a time when we should 
be simply working with puzzle-pieces as you would any jigsaw puzzle. 
Again, HTTP URIs, RDF statements, and Relation Semantics == all you need 
in regards to constructing and using the puzzle-pieces and piecing that 
AWWW facilitates.

> under the control of a non-profit like the Electronic Frontier
> Foundation, Creative Commons, or GNU Foundation.

That can never be an accepted assurance. Never.


> That site will go away
> in time if this stuff is implemented in the browser. 

How will that be implemented in the browser? On who's timetable, under 
what market (or "opportunity costs") driven duress? Companies ultimately 
only respond to "opportunity costs".

> If not, then an
> independent, trusted organization will be put in charge of it.

"Independent trusted orgranization" is just a phrase comprised of three 
words. What it actually denotes and connotes is quite nebulous. Trust 
never works that way, it has to be the outcome of some kind of "proof of 
work". That's why crypto is crucial to Trust.

>
> As for the rest of your list, we're aligned. There is very little that
> we're not aligned on. :)

Good to hear. I just need to nudge you re. mutual inclusion in regards 
to specs and standards :-)
>
> -- manu
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen