Re: Web Identity 1.0 -- Draft Spec

makes me think of a function that looks for the RDF / # / ‘200'; and goes to get a gravatar of the page author via a foaf record somewhere, and present it in the browser (perhaps even with a microblog feedback or 'tweet’ function… )


re: webidentity / webid / ontological / interoperability methods for app developers; to start with, there are elements of ‘person’ that can’t be easily described by documents or resources.

Interpretatively relied upon as a basis in fact; which therein, the notion of time plays a role - thinking our loud, perhaps a 'metaphysical neurosis’ is one concept that might be difficult to graph effectively in terms of ‘knowledge’ as apposed to subjective meaning.  Even DSM definitions get updated, and when they are - practitioners may still refer to the previous definitions without taking note of the newer iterations or methods available. 

The descriptive word ’tree’ is of course interpretively different to ‘person’; but not to the extent where ’tim’ can differ from ’timbl’ to others, or persona therein.   Perhaps reading http://lists.w3.org/Archives/Public/www-tag/2009Aug/0000.html there were always the idea of ‘documents’ and ‘resources’; therein, persona is somewhat pre-built.?

How that translates to defining my contributions on w3.org/lists#timh, let alone where a query like that might link-to, is another story entirely. 

I think the complication is embodied functionally that has traditionally existed ever since i’ve used computers, the idea that the database and the interface and/or program all live on the machine - from floppy to Facebook - it’s a rather standard kind of concept - but functionally, this is now changing (or capable of changing?).  Data about us, is stored primarily by us; and records relating to us, can be more easily made available to us also. 

A governments departmental records about you is (currently) often not available to you; but say, a world exists where they become accessible or even stored by you, then the procedural processes set-up in the government department to protect your privacy, doesn’t matter anymore; it’s up-to you to do that, and the government department to endorse your right to do that.  

perhaps tehre's an energy benefit which means government providing you an ‘information account’ is cheaper and less energy intensive than storing and copying the thing all over the place.   

So to explore that concept;  In Australia, after much expenditure they created ‘personally controlled health care records’; now how those records are actually personally controlled, is really a legally subjective term, rather than a practical nuance of limited liability by way of asserted ‘ownership’ for esoteric purpose, or something along those lines…  

now for an array of purposes it’s probably best we don’t end-up with a medical ‘credit file’ that asserts the equity of existence upon people.  Lawyers and business partnership breakdowns can already be very dangerous; and whilst i’ve seen issues in the US (for example) other regions have different philosophical attitudes, and challenges to how these work with insurance risk-management or strategic marketing specialists is an adventure that will appears when critical mass is achieved.  hopefully by that stage the IPR industry will have evolved also. 

So the ability for data to be portable (if you though a bank was about to go under, you’d probably want to get your money out first); and standardised interoperability between providers is also kinda important.  

my gov. health card might need a new URI / URL to target - but perhaps it doesn’t matter where it’s stored; so long as it’s not too easy to loose in a bushfire, or flood, etc.  

(the security embodied in an array of manila folders between practices, with doctors who write letters or use telephones; is currently very difficult to improve upon). 

in any-case…

:  also responding to:
: http://lists.w3.org/Archives/Public/public-rww/2014Jan/0023.html
: http://lists.w3.org/Archives/Public/public-webid/2014Jan/0019.html


http://www.w3.org/DesignIssues/CloudStorage.html  says; 'WebIDs (a.k.a FOAF+SSL)’ 

some App examples; without RWW-LD or WebID (kinda, don’t want to get into semantics about whether Facebook is foaf enabled.) 
 http://mindmup.com/ 
 http://www.layoutit.com/build 
 http://codepen.io/ 
 https://www.draw.io/

taskify.org  is perhaps the best example i can resource that goes someway down the path needed (with non-public data), but there still doesn’t appear to be enough method to standardise the integration between one of those apps defined above and a RWW-LD storage / HTTP service, that’s decoupled from the platform developers notions on how to do it. 

App builders really shouldn’t care if a user wants to use rww.io, or data.fm, or ods or stample, etc. (and that the URL can obviously change, but collectively i’ll them RWW-LD accounts or services).  not wanting to mix-up products with company names; but i data.fm is rather clear in function, just not very ‘pretty’ (and separately, looking at how to parse image metadata, store it in a .meta file? anyhow…) 

APP REQUIREMENTS? - PROCESS / REQ's? 
1. I need to authenticate on their site. (say hi, this is me)
2. I need to nominate where i wish to ‘store’ data (developers site provides function, i store and publish on my site)
3. I need to auth. app to store data on my storage location (my HTTP connection is with Mindmup, or layoutit — whereas the app, is providing one interface to me, the other to my storage / rww-ld account, identified as ‘app32-mindmup.com’ or whatever (agent)) 
4. i need to store auth. info (ideally on my storage location? mindmup.com site wants userid/password) 
5. I’d like to package stuff in a transportable manner.  (build layoutit - then post to client, without my site access details - they can use it, but they’ll need to set-up their own account).

I might have a few RWW-LD.  Might have one at home, on a clever little NAS (perhaps because the satellite is a bit slow at peak times; so it’s easier or cheaper to replicate overnight), one on a staging or online back-up server/service somewhere - another - is owned by a 3rd party but i have access to it because i provide support.  (and have made an update and some different ideas applying the MindMup doc to their environment.).

Same kinda thing goes for other sorts of documents (js, html, css, PSD, etc.); So i’d like to browse the forks (versions accessible to me) but have assigned one storage location for the session (on one of my rww-ld accounts).  The interface might tell me it hasn’t been able to contact s3.mystorage.profile.info; so the fork is based on ‘known’ data. 

Each ‘peer’ has one or more webid’s associated to them; and on a storage service somewhere auth. documents exist (ideally on something i control, if they’re my auth. details / documents, website can use my public foaf uri applied to session data) 

FYI - melvin sent; http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf recently. 

So in theory; the means in how the app does the auth; so long as it’s using webid’s may not matter as much as whether the methods are supported on the various rww-ld platforms.   Perhaps it is not upto the app to define auth; other than perhaps requesting a level of claim / endorsement that suits the app’s needs.

How that’s turned into standards, i’m really not sure, perhaps if the examples exist already - post a link? 

as noted previously; if i get into a car accident or something; i’m more than happy for the GP to go get my record and treat me; i think it’s important.  If i had a chronic disease, i’d be happy to share data for research purposes; but i’m not really happy with a friend, of a friend who’s a doctor accessing my record for some other purpose, that has nothing (positive) to do with my wellbeing; and perhaps also importantly, even in those fields of ‘knowledge’ one little fact changes, and all their assumptions go out the window. 



On 11 Jan 2014, at 4:52 am, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 9 January 2014 16:21, Timothy Holborn <timothy.holborn@gmail.com> wrote:
> I think I've used, built every known webid enabled service / system / platform out there, i'll make a list at some stage: from a user perspective, it's very confusing...
> 
> I honestly do not think it describes a human well, or acknowledge a specific human on a keyboard.  It's a necessarily element, like a bank-card to an account holder - but the card or the account, is not the person and the account / card can be labelled as to describe a relation, rather than the person: therein, agent.
> 
> Webid to users means login with a certificate.  I've now got so many certificates, and I think I've even lost some - don't even remember the services I lost them from; and let's not get into early bitcoin mining testing; anyhow, it probably should mean, I have authorised devices, accounts, relationships, agreements: that can do predefined tasks without my direct intervention (unless I've set out a flag, or whatever).
> 
> So, I recon the identity chain isn't finished yet, unless everything is public except for what programmers develop and manage specifically, which isn't the mission...
> 
> Leaky abstraction threatening standards interoperability (not many webid users out there ATM) vs. one ring to rule them all - there's a few other options... 
> 
> In theory, every user becomes an identity provider to some level: even if it's simply acknowledging they own a computer and an account where they provide access to resources to others. 
> 
> At the moment, identity providers are centralised.  So I think it's functionally quite different.
> 
> If you are interested in some of the history of how the web came to be the way it is today, this is a great post:
> 
> http://lists.w3.org/Archives/Public/www-tag/2009Aug/0000.html
>  
> 
> Just ideas, I'll keep thinking.
> 
> Notes below.
> 
> Sent from my iPad
> 
> On 10 Jan 2014, at 1:04 am, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
>> On 1/8/14 10:27 PM, Timothy Holborn wrote:
>>> re: G+[1] i agree with Kingsley almost; and the underlying differentiation, is in seeking to define 'persona' as a separate 'identity' for the purpose of identity management. 
>>> 
>>> Some ideas (sorry for the length; ideas are still draft).
>>> 
>>> WEBID
>>> There's a couple of different sorts of 'things' that interact.  WebID seems to make the most sense for 'things that speak internet' (and knows what to do with a cert).  
>>> WebID [2] seems to provide a method to deploy x509 with RDF, which is beneficial for IoT / WoT; therefore reinforcing identity / privacy methods, especially when applied to an RWW Account (LDP / RDF + storage + base services
>> 
>> Not really. A WebID is a term that refers to the use of HTTP URIs for denoting (naming or "referring to") agents (entities such as people, organizations, sofware, robots, and anything else capable of mechanized operation). Its sole purpose is entity denotation, that's it. 
>> 
> http://www.w3.org/wiki/WebID Or updated version https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
> 
>> Unfortunately, during the early days of WebID, it got conflated with  Discovery and Authentication, as reflected in your characterization above re. X.509  and RDF. 
>> 
>> In recent times the following have been established to be distinct:
>> 
>> 1. WebID 
> 
> So, foaf?  What's different here from foaf.
> 
>> 2. WebID + TLS authentication protocol -- which is based on RDF, X509, and existing PKI. 
>> 
>> Once we establish that a WebID is simply a denotation mechanism, the rest of the stack can take shape without falling into the usual "leaky abstraction" tar-pit i.e., where a spec fails (woefully) when it simply seeks to push an agenda rather than deliver standard interoperability via loosely coupling or related parts. Put differently, the spec fails the jigsaw-puzzle-pieces test. 
>> 
>> [SNIP]
>> -- 
>> 
>> 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
>> 
>> 
>> 
>> 
> 

Received on Saturday, 11 January 2014 02:30:30 UTC