- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 27 Jul 2021 19:01:32 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYhKPLkuzDRwjBYN8t-aD41da810nLcTncm2bPUP-Dk1Ctw@mail.gmail.com>
On Tue, 27 Jul 2021 at 17:58, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 7/27/21 5:52 AM, Melvin Carvalho wrote: > > > > On Tue, 27 Jul 2021 at 04:22, Kingsley Idehen <kidehen@openlinksw.com> > wrote: > >> On 7/26/21 1:08 PM, Melvin Carvalho wrote: >> >> >> >> On Mon, 26 Jul 2021 at 18:27, Ted Thibodeau Jr <tthibodeau@openlinksw.com> >> wrote: >> >>> >>> On Jul 26, 2021, at 02:34 AM, Melvin Carvalho <melvincarvalho@gmail.com> >>> wrote: >>> >>> >>> Ah, I see the issue here >>> >>> The current WebID spec is in fact tightly coupled to Turtle (and http) >>> via "MUST" >>> >>> https://www.w3.org/2005/Incubator/webid/spec/identity/ >>> >>> >>> Those who fail to read the "Status of This Document" are >>> doomed to pain and agony all the days of their implementation. >>> >>> To wit: >>> >>> This document is produced from work by the W3C WebID Community Group >>> <http://www.w3.org/community/webid/>. This is an internal draft >>> document and may not even end up being officially published. It may also be >>> updated, replaced or obsoleted by other documents at any time. It is >>> inappropriate to cite this document as other than work in progress. The >>> source code for this document is available at the following URI: >>> https://dvcs.w3.org/hg/WebID >>> >>> This document was published by the WebID CG >>> <http://www.w3.org/community/webid/> as an Editor's Draft. If you wish >>> to make comments regarding this document, please send them to >>> public-webid@w3.org (subscribe >>> <public-webid-request@w3.org?subject=subscribe>, archives >>> <http://lists.w3.org/Archives/Public/public-webid/>). All comments are >>> welcome. >>> >>> Publication as an Editor's Draft does not imply endorsement by the W3C Membership. >>> This is a draft document and may be updated, replaced or obsoleted by other >>> documents at any time. It is inappropriate to cite this document as other >>> than work in progress. >>> >>> In other words: This is not a spec, current or otherwise. >>> >>> It is very much an Editor's Draft, coming from the discussions >>> of what was then an Incubator Group, and transformed into a >>> Community Group, but really reflecting the opinions of the >>> Chair who was doing double-duty as Editor, much more than of >>> the group as a whole. >>> >>> It does not come close to reflecting consensus of that old XG >>> (of which I was a member), never mind transition to a Candidate >>> Recommendation, and further progress down the REC-track was >>> likewise years away, as there was never a WebID Working Group. >>> >>> In my opinion, it should never have received the Respec skin >>> it has, which makes it *look* like something it isn't, and >>> at a minimum, W3C should find a way to put the watermarks >>> now in common use on draft specs in the github.io space onto >>> all the old draft specs that will otherwise continue to draw >>> people into thinking that output of one person's keyboard >>> have the same weight as the work product of several if not >>> dozens of people intellectual and technical efforts. >>> >> >> Good points. I guess it was last updated over 7 years ago and both of >> the editors are no longer active >> >> And a lot has changed in that time! >> >> >> >> Yes, but it was never a spec endorsed by the W3C. >> >> Today, it still isn't a spec endorsed by the W3C. >> >> All we have in reality is "WebID" as a colloquialism for an HTTP >> Identifier that denotes an Agent, and is generally conflated with a >> protocol for credential verification that goes by the moniker "WebID-TLS" . >> > > Makes sense. Tho WebID still is in use by some of the RDF folks, and I > think they would argue that RDF/Turtle is mandated. > > > Let them, at the end of the day freedom should reign supreme :) > > > In time that may change, but in years probably, given the run rate > > >> I am betting on verifiable credentials working via an emergent de facto >> protocol that's adopted en masse by developers at some point. However we >> get there, the following constants will be in play: >> >> 1. Logic as the Conceptual Schema >> >> 2. Resolvable Identifiers >> >> 3. Credentials that manifest as an Entity Relationship Graph comprising >> Resolvable Identifiers >> >> 4. Credential verification protocol >> > > I think what we need is JSON Objects, denoting an Agent, that can > optionally have a URI. > > > There isn't a "one size fits all" solution to this matter. > > Folks should simply build around an abstract core and ship apps and > services. The notion of one spec adopted by the world will not work, IMHO. > > > > If it has an abstract model that's fine also, which allows middleware > solutions, and you can put it in a data store, including redis, mongo, > browser stores, virtuoso, quad stores etc. > > > It is 100% about being abstract. > Why is it 100% about being abstract? ie what's the benefits and what are the possible abstractions? > > > > Add an attribute for fingerprint or public key or delegate. This should > be a single field, rather than more granular terms like modulus/exponent > etc. which was never completed > > Put the fingerprint / key / provider in the doc for proof. Perhaps > fingerprint should be preferred here. (even ni:/// hashes) > > > Whatever works for developers and the end-users they will ultimately be > bringing onboard. > > > > And the same JSON object can be used to create a friend graph, chat, > signatures, and all sorts of other social functionality, not just auth -- > this is where we create the real facebook alternative > > > Any kind of doc comprising structured data will do. > > The goal of an endeavor aimed at developers should be: > > 1. Developer Adoption > 2. Application Development and Deployment > > User uptake is driven by the success of App Deployment & Marketing. It is > never about specs, as WebID has itself reminds us. > > > > Align this with real world usage, including fediverse, VCs, but with clean > separation of Objects and Documents, following from REST like principles > > > See comment above. > > > > ie its really what people are already doing today, so it might not need a > name as such. But a name and a documentation could help. Perhaps your > NetID or YouID would be a good code name > > I guess what's more important is the documentation and examples. It's a > bit scattered around on chats, mail lists, blog posts. > > Maybe an idea would be to use our wiki to write down some docs and > > I looked in our wiki for a page on Identity but couldnt find one. Perhaps > we could start one or ... > > It turns out we have an ancient draft spec for the read write web here; > > https://www.w3.org/community/rww/wiki/Draft_Spec#Identity > > Which includes an identity section > > Maybe it might be a good place to note down ideas from these > conversations, based on what we've learnt over time -- as it's a wiki feel > free to dive in -- and perhaps I can do some modernization work ... > > > Yes. > > > Kingsley > > > >> -- >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Home Page: http://www.openlinksw.com >> Community Support: https://community.openlinksw.com >> Weblogs (Blogs): >> Company Blog: https://medium.com/openlink-software-blog >> Virtuoso Blog: https://medium.com/virtuoso-blog >> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers >> >> Personal Weblogs (Blogs): >> Medium Blog: https://medium.com/@kidehen >> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ >> http://kidehen.blogspot.com >> >> Profile Pages: >> Pinterest: https://www.pinterest.com/kidehen/ >> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen >> Twitter: https://twitter.com/kidehen >> Google+: https://plus.google.com/+KingsleyIdehen/about >> LinkedIn: http://www.linkedin.com/in/kidehen >> >> Web Identities (WebID): >> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i >> : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this >> >> > -- > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Home Page: http://www.openlinksw.com > Community Support: https://community.openlinksw.com > Weblogs (Blogs): > Company Blog: https://medium.com/openlink-software-blog > Virtuoso Blog: https://medium.com/virtuoso-blog > Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers > > Personal Weblogs (Blogs): > Medium Blog: https://medium.com/@kidehen > Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/ > http://kidehen.blogspot.com > > Profile Pages: > Pinterest: https://www.pinterest.com/kidehen/ > Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen > Twitter: https://twitter.com/kidehen > Google+: https://plus.google.com/+KingsleyIdehen/about > LinkedIn: http://www.linkedin.com/in/kidehen > > Web Identities (WebID): > Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i > : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this > >
Received on Tuesday, 27 July 2021 17:01:59 UTC