Re: Was mandating WebIDs be IRIs ever discussed (as opposed to them 'just' being URIs)?

> On 4. Jul 2022, at 22:04, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> WebID-TLS works with TLS client certificates. Are there any protocols that work with TLS other than HTTP? If not then I would say the only legal URI scheme is https.
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#the-webid-authentication-protocol

Around 2008 when we started foaf+ssl, mentioning https was thought to be deal breaker, not
only for then, but for many that was a problem that could never go away. Now
with https://certbot.eff.org it both easy to automate the process and use of tls is widely 
accepted. 

So I definitely think that https should be the default in all the examples now, and in a way
http:// reserved for testing or intranets… And this is not because of reliance on 
WebID-TLS, but just because otherwise the RDF served could be changed by a MiM. 

As for IRIs I think that is too much work to get into. We don’t have
people full time on a payroll to write specs on this, and there are many other 
protocols and things needing to be done with higher priority. As far as I understand 
IRIs are just a standard for software to be able to keep a clean model for what lies
behind URIs. In the end we need our protocol to work for https, and there are maps
form https IRIs to https URLs. We should rely on standards that explain how to make
those maps. 

On the Json-ld question, Aaron Coburn use case was predicated on json-ld being
a better default for the OpenID JSON based community. It does seem a lot more reasonable
now that json-ld parsers are more widely available to have json-ld and turtle as two formats
one or the other of which must be served. That means that generic clients would need to parse
both. But in specific cases like with Solid OpenId, the link to the OpenId can require one
of them to be present, removing the need of OpenID folks to understand Turtle. In the
end Aaron decided to call that URL something else, which is also a good solution.

The aim is not WebID but building decentralised social networks based on LinkedData
principles. We now have Solid progressing nicely with a number of server implementations
as well as client implementations, and a huge amount of work still to do still there. 


Henry

> 
> On Mon, Jul 4, 2022 at 9:10 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> On Mon, Jun 27, 2022 at 8:15 PM Nathan Rixham <nathan@webr3.org> wrote:
> I guess WebID can be any... Something used in WebID-TLS may need to be http(s).
> 
> We actually nailed the initial definition of WebID at TPAC, based on a formulation you came up with on IRC.
> 
> This later went to the group and there was some to and fro regarding redirects -- long story short, timbl didnt like redirects because they're a pain -- others felt 303 was a worthwhile deployment pattern, but this always muddies the waters
> 
> It was a branding exercise, to create a practical definition that folks might use.  Whether or not that exercise was a success is debatable, but better to get behind something and build, than argue about fine print.
> 
> That was about 8 years ago, and since then things have stalled.  Though there was some movement in the last year, IMHO we'd benefit from a chair to drive things forward, but unsure if anyone has time for that
> 
> There's currently some momentum towards completing the draft spec, and modernizing it a bit.  For example to add JSON-LD and a context, is generally regarded as a good thing.  That's somewhat political though.
> 
> I would favour at some point a clean modern webid 2.0 spec, which was simple, minimalist, practical.  But at the same time, is there a need for it?  Having yet another w3c spec that fewer than 100 people use is a bit cringe.  So we're a bit stuck in general.
> 
> Is there a pressing need to have IRI's and webid.  On some reflection, I think that unicode characters could increase the attack surface.  Is there some limitation in ascii chars?  It also plays nicely with subdomains, which we decided to use for webid's in Solid etc.
>  
> 
> On Mon, 27 Jun 2022, 19:11 Eric Jahn, <eric@alexandriaconsulting.com> wrote:
> Why does it have to be an HTTP IRI?  Why not, just an IRI (any protocol)?
> 
> Eric Jahn
> CTO/Data Architect
> Alexandria Consulting LLC
> St. Petersburg, Florida
> 727.537.9474
> alexandriaconsulting.com
> WebID
> 
> 
> On Mon, Jun 27, 2022 at 1:22 PM Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 6/27/22 10:52 AM, Pat McBennett wrote:
>> Hi,
>> 
>> I just wanted to first ask if anyone here knew of any existing discussions at all (either here in this mailing list (as I can't find anything directly relevant when I search this list for 'IRI'), or anywhere else public) on updating the current statement in the draft spec [1] (i.e., ""A WebID is an HTTP URI") to use the term IRI instead of URI?
>> 
>> (Note: I'm very deliberately not even mentioning the term HTTP in that definition - as that is a completely separate discussion point (i.e., getting into DIDs and IPFS, etc.))
>> 
>> I don't pretend to know the history behind efforts to definitively define what an IRI is - but I understand that IETF 3987 [2] never actually became an official standard (or did it?).
>> 
>> I understand that the whole area of clearly defining what we mean by URL, URI, or IRI is probably still a mess. This was brilliantly articulated back in 2016 in this blog entry [3] by the maintainer of cURL (Daniel Stenberg): "Not even curl follows any published spec very closely these days...There’s no unified URL standard and there’s no work in progress towards that. I don’t count WHATWG’s spec as a real effort either".
>> 
>> The reason I ask this question at all is because the RDF 1.1 Concepts and Abstract Syntax makes it explicitly clear that all identifiers in RDF are IRIs (as defined by IETF 3987, so whether that is an official standard or not), and it's clear from section "3.2 IRIs" that the reason for RDF explicitly stating the use of IETF 3987 IRIs over URIs is:
>>   "IRIs are a generalization of URIs [RFC3986] that permits a wider range of Unicode characters."
>> 
>> Therefore I interpret that as saying that RDF mandates IRIs so as to be as inclusive as possible of character sets to allow people from all around the world to use their native languages to mint identifiers. (Seems like quite a laudable intent to me!)
>> 
>> So my question, simply re-stated, is: has anyone discussed the idea of mandating WebIDs be IRIs too, for the same reason - i.e., to explicitly be as inclusive as possible of global character sets?
>> 
>> (Seems to me like WebID has *even more* reason to be explicitly inclusive of character sets for identifiers than RDF even, since WebIDs are expressly intended to identify people (as well as organizations, and IoT devices, and 'agents', etc.))
>> 
>> Cheers,
>> 
>> Pat.
>> 
>> 1 - https://www.w3.org/2005/Incubator/webid/spec/identity/#:~:text=a%20given%20Server.-,WebID,A%20WebID%20is%20a%20URI%20with%20an%20HTTP%20or%20HTTPS%20scheme,-which%20denotes%20an
>> 2 - https://www.ietf.org/rfc/rfc3987.txt
>> 3 - https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/
>> Pat McBennett, Technical Architect
>> 
>> Contact  | patm@inrupt.com
>> 
>> Connect | WebID, GitHub
>> 
>> Explore  | www.inrupt.com
>> 
>> 
>> 
>> 
>> This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.
> 
> 
> Hi Pat, 
> 
> Long story short, your point is valid. 
> 
> Challenge:
> 
> Evolving the WebID spec is fundamentally difficult, IMHO.
> 
> A WebID should be an HTTP IRI that denotes an Agent. 
> 
> How that becomes part of the spec is a completely different matter :(
> 
> -- 
> 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 Wednesday, 6 July 2022 13:03:27 UTC