Re: Simple WebID, WebID+TLS Protocol, and ACL Dogfood Demo

On 8/7/13 1:34 PM, Nick Jennings wrote:
> Hi Kingsley,
>
>  Thanks for the links. Trying out the first link 
> (http://youid.openlinksw.com/) now, some notes:
>
> 1. Certificate Name: maybe there could be some examples of ways to 
> name your certificate. I was speaking with Henry Story about this 
> during the OHM2013 conference, because at one time I had inadvertently 
> 3 different WebID certs in my browser, when I would visit a WebID 
> enabled site, I'd have no idea which one to choose, they were all the 
> same "Nick Jennings ..." ... He suggested that I give them unique 
> names like "Work" "Home" "Junk" etc. so I know when to use them in 
> which cases... but this isn't very obvious to a new user.

Which screen?

There are two points in the process where names are required:

1. Canonical Name (CN) component of the Distinguished Name (DN) -- note 
this is an X.500 naming structure
2. pkcs#12 file -- the secure file to which your certificate, public 
key, and private key are saved, if you don't take the <keygen/> route.

Here are some Public Key URIs that shed light on the kind of values I 
provide re. #1:

1. 
http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fcertgen%2Fkey%2F8758 
-- note "/CN=Kingsley Uyi Idehen (LinkedIn Latest).."
2. 
http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fcertgen%2Fkey%2F8954 
-- note "../CN=@kidehen (Twitter).." .

Browser UIs aren't so great re., handling of X.509 certificate selection 
and presentation. I use the patterns above to address challenges in this 
area.

>
> In general, that brings up some thoughts for me, maybe here's the 
> place to share them. It would be cool in browsers could bake the idea 
> of a WebID into the persona/profile of the browser session. (ie. 
> chromes profiles, and firefox has a profile plugin). Just allowing (by 
> default, i guess) one WebID per persona. This way you are encouraged 
> to manage different profiles at the browser level, rather than 
> juggling a bunch of certificates with naming hacks to figure out which 
> is which... ?

No, its a browser UI problem, as per my comments above. I don't know 
which browser you are using, but I can tell you the experience varies. 
My personal preference order is as follows:

1. Mac OS X Keychain -- Safari and Chrome
2. IE
3. Firefox and Opera -- which implement their own browser hosted 
keystores (instead of leveraging the native OS key store) which is the 
root of their UI/UX problems.
>
>
> 2. With firefox, after filling out the form, I get a download dialogue 
> for the cert instead of it installing into the browser. So I saved, 
> then went into preferences and "import" ... which was successful with 
> "Successfully restored your security certificate(s) and private 
> key(s)". Previously, with my-profile.eu <http://my-profile.eu>, this 
> was automatically installed into the browser (I was using Chrome then).

Yes, that's because we deliberately don't default to <keygen/>. You can 
select <keygen/> from the drop down and the certificate will be 
generated and then saved to the Firefox key store. We just believe that 
pkcs#12 files are more flexible since you can route them via email from 
desktop to phones and other devices, safely.

> Though I guess it's better to have it export/save by default so you 
> can install the same cert on any number of browsers without hassle.

Yes, and other device form factors.

> Still, it creates more steps and could be confusing for new users.

Yes, we aren't their yet re. total ease of use (via step contraction) 
for end-users. We have an update coming that compacts the steps while 
also attending (in more obvious ways) to the needs of those with 
existing FOAF documents.

>
>
> 3. After importing the cert, when I go to rww.io <http://rww.io>, it 
> asks me to select a cert (which I do) but then when I view 
> silverbucket.rww.io <http://silverbucket.rww.io> it still says in the 
> upper right "webid login"... I can't tell if I registered this spot 
> and it's working, or not. There's no real user feedback as to login 
> state. Same with taskify.org <http://taskify.org>. I don't know if 
> this is a site UI problem or a cert issue.

You can also try:

1. http://id.myopenlink.net/ods/webid_demo.html
2. goto: 
<http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/WebID-ACL-Demos/> 
and attempt to edit 
<http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/WebID-ACL-Demos/simple-shared-turtle-doc.txt> 
(this document has a WebID+TLS based ACL that only allows identities 
associated with a verifiable WebID to edit).

>
> Would be cool to have login state also baked into the 
> browser/profile/webid. I imagine something like what chrome has, an 
> avatar in the upper-left which indicates who you "are" at the moment, 
> with an overlay (padlock?, green/red light?) icon of your login state 
> for that particular site.

Session login and logout is the one area of challenges for WebID UX due 
to problems at the browser level. WebID+TLS is really about NoLogin so 
it poses some challenges i.e., getting browser vendors to play ball, 
amongst other things.

>
>
> I know most of my suggestions are for browser developers, I just 
> wanted to share my overall impression of WebID. I think it's a great 
> idea, but it still feels very intangible as a user.
> -Nick

It's an option amongst many for login based identity authentication. It 
stands on its own re. NoLogin based identity authentication, which (as 
stated earlier) gets the browser UI/UX in a pickle :-(


Kingsley
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 7, 2013 at 6:54 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 8/7/13 12:43 PM, Nick Jennings wrote:
>>     It would help if there was some way one could reliably get and
>>     manage WebID. As it is right now, neither rww.io <http://rww.io>
>>     nor my-profile.eu <http://my-profile.eu> (which are the only ones
>>     I know about) are functioning in terms of generating a WebID for
>>     the browser.
>
>     Does this also apply to:
>
>     1. http://youid.openlinksw.com
>     2. http://id.myopenlink.net/certgen .
>
>     Note, both of these provide the pkcs#12 option (as opposed to
>     keygen) by default.
>
>     In addition, if you already have a FOAF profile doc, use the
>     second tab (we forgot to list FOAF where you see OpenID). Then
>     follow the wizard to then end of the process which basically
>     provides content for you to manually add to your FOAF profile. Of
>     course, if you don't manage your own profile document, you take
>     the defaults which leads to the profile document be hosted at
>     id.myopenlink.net <http://id.myopenlink.net>.
>
>     As I type, I just realized we overlooked a key feature and that's
>     setting an ACL on the profile document generated on
>     id.myopenlink.net <http://id.myopenlink.net> so that you control
>     the ACLs going forward.
>
>     Note to self (and rest of OpenLink Data Spaces team), that's a new
>     feature zilla :-)
>
>
>     Kingsley
>>
>>     I had some from my-profile.eu <http://my-profile.eu> that were
>>     generated several months ago, but I removed them all during some
>>     tests and was unable to get a new one. I tried in both Firefox
>>     and Chrome. Anyone having trouble as well?
>>
>>
>>
>>
>>     On Tue, Aug 6, 2013 at 8:01 PM, Kingsley Idehen
>>     <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>
>>         All,
>>
>>         Following the earlier posts about WebID (and by implication,
>>         WebID+TLS), here is a very simple demonstration of how we can
>>         put this technology to good use re., protected document
>>         authoring and editing.
>>
>>         For this exercise I've performed the following steps:
>>
>>         1. Created a protected Turtle document at:
>>         <http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/WebID-ACL-Demos/simple-shared-turtle-doc.ttl>
>>
>>         2. Used WebID (Agent entity type denotation), WebID+TLS (for
>>         agent identity authentication), and an ACL (itself expressed
>>         in Turtle) to create a data access policy that enables anyone
>>         read the document's content, but only allowing those with
>>         verifiable WebIDs to perform read, write, and delete operations.
>>
>>         This entire exercise is driven by Linked Data.
>>
>>         Let everyone know how you get on :-)
>>
>>
>>         -- 
>>
>>         Regards,
>>
>>         Kingsley Idehen
>>         Founder & CEO
>>         OpenLink Software
>>         Company Web: http://www.openlinksw.com
>>         Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>         <http://www.openlinksw.com/blog/%7Ekidehen>
>>         Twitter/Identi.ca handle: @kidehen
>>         Google+ Profile:
>>         https://plus.google.com/112399767740508618350/about
>>         LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
>
>
>     -- 
>
>     Regards,
>
>     Kingsley Idehen 
>     Founder & CEO
>     OpenLink Software
>     Company Web:http://www.openlinksw.com
>     Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile:https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>


-- 

Regards,

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