Re: Loosely Coupled Identification and Authentication Demo -- Microsoft IdP

On 6/30/14 11:46 AM, Peter Williams wrote:
> I will play with this in detail, later in the week. As usual, you are 
> redefining the baseline.
>
> Ive become well immersed in the mobile security tool chains planned (a 
> year or two ago) that align with the “official” line on commodity 
> security, set in the days when vendor cels and product managers at 
> microsoft enjoyed regular cosy coffee sessions  general Keith. Of 
> course, that is all on some disrepute, now. So im interested in  fresh 
> thinking, that takes into condideration the fact that “now everyone 
> knows…” that untrustworthiness is endemic. How does one design, given 
> this new reality - where any and all assurance is now inherently 
> suspect (since explicitly subverting assurance sources is part of the 
> reality).
>
> Unlike the corporations still stunned into silence at the public 
> exposure of the reality of the threat environment (now known to 
> include generalized surveillance, systemic dossier collection, and 
> layer upon layer of untrustworthy messaging making any us based entity 
> - including w3c - an untrustworthy body on crypto/security), we dont 
> have any such compromised history.
>
> Not trying to sound like a nut job, more one of asking a science 
> question that recognises the reality (rather than doing the larger 
> vendor’s ostrich act wishing for the status quo of a year or two ago).
>
> I dont necessarily expect any solution (and perhaps dont really even 
> want a technical answer to what is a political question). But 
> registering the threat of state sponsored subversion seems the right 
> thing to do. How does the web react, to being militarized?

Logic and Relations.

There is nothing technical about the underpinnings here. We just have 
Relations and Logic woven into the Web, courtesy of its underling 
architecture.

Ultimately, you can only trump social and political vulnerabilities via 
relations and logic.

The poor introduction of RDF is the only reason why these sometimes 
appears to be novel. By design, the Web allows us to achieve what was 
otherwise too challenging i.e., making relations and logic first-class 
citizens, without platform lock-in.


Kingsley


>
> Sent from Surface Pro
>
> *From:* Kingsley Idehen <mailto:kidehen@openlinksw.com>
> *Sent:* ‎Monday‎, ‎June‎ ‎30‎, ‎2014 ‎6‎:‎18‎ ‎AM
> *To:* peter Msn <mailto:home_pw@msn.com>, public-rww@w3.org 
> <mailto:public-rww@w3.org>, public-webid@w3.org 
> <mailto:public-webid@w3.org>
>
> On 6/30/14 8:22 AM, Kingsley Idehen wrote:
> > On 6/29/14 7:24 PM, Peter Williams wrote:
> >> We cannot have a “more” list of 3 million icons. And I have no
> >> intention of using an American brand (like Microsoft or Google, or
> >> ...l) for anything that has the slightest value.
> >>
> >> What do we do?
> > Peter,
> >
> > You don't have to remember or type in a URI when accessing a protected
> > resource using the Virtualized Authentication Layer (VAL) referred to
> > in my earlier post. I've produced a screenshot from my ODS (OpenLink
> > Data Spaces) based Briefcase (our equivalent of OneDrive, Dropbox,
> > Google Drive etc..) that displays the current authenticated identity
> > associated with a user agent session [1].
> >
> > If I wanted to make a more fine-grained acl, scoped to a specific URI,
> > I would simply copy and paste that URI for use in my ACL. As for
> > users, they never need to type anything when accessing protected
> > resources, they simply click on a button.
> >
> > If you wanted to use your Microsoft URI in the SAN of an X.509 cert
> > you have two choices:
> >
> > 1. Simply generate your x.509 cert (Digital Identity Card) using YouID
> > -- take the Microsoft PdP (Profile Data Provider) route with one of
> > the following as the IdP (Identity Provider -- service that stores
> > public part of your Identification oriented Claims) OneDrive, Dropbox,
> > Google Drive etc..
> >
> > 2. Do it by hand using provider certificate generator provided by
> > relevant operating system.
> >
> > Either way, our NetID-TLS (a superset of WebID-TLS) protocol with
> > handle identity claims authentication. In short, that's what happens
> > when you click on the buttons presented by the VAL dialog.
> >
> > Links:
> >
> > [1] http://susepaste.org/35303595 -- My Identifier from Microsoft's
> > Data Space (which is comprised of millions of other user accounts for
> > every Microsoft app/service user)
> >
>
> Here's WebID-TLS based authentication results page based on a YouID
> generated Identity Card where the WebID is derived from interaction with
> a Microsoft Account via OAuth and the WebID-Profile document is deployed
> using Microsoft OneDrive. Net result:
>
> 1. a WebID -- scoped to Microsoft OneDrive (following successful
> interaction with Microsoft Identity Provider services)
> 2. an X.509 based Digital Identity Card (Cert.) .
>
> When generating the Identity Card the user simply clicks on a button
> that triggers the handshake and profile data exchange with Microsoft's
> services.
>
> Note, even if the Microsoft user doesn't have an actual Digital Identity
> card, I can still make an ACL based on their Microsoft URI (e.g.,
> <https://profile.live.com/cid-3a02f98c12fc49f5>) using the Microsoft
> Accounts specific authentication API. Basically, this is where the
> NetID-TLS superset of WebID-TLS comes into play.
>
>
> Links:
>
> [1] http://bit.ly/TwdZ10 -- actual WebID-TLS based authentication
> results page
> [2] http://bit.ly/1sRcg70 -- YouID generated artifacts collection for my
> Microsoft Account, deployed via OneDrive and mounted to my ODS-Briefcase
> (since these storage service providers don't provide open directory
> browsing without social media contacts data related payments)
> [3]
> http://kingsley.idehen.net/DAV/home/kidehen/Public/OneDrive/YouID/IDcard_Live_140630_084317/index.html 
>
> -- HTML based variant of my Digital Identity Card .
>
> -- 
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen 
> <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: 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
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this