Re: HTTPSig authentication

On 6/13/23 5:00 AM, Henry Story wrote:
> Hi,
>
>     I have been working on an Authentication mechanism working purely at
> the HTTP layer by building just very lightly on the IETFs “Signing 
> HTTP Messages”
> Specification.
>
> I gave a demonstration about it at last Wednesday’s Solid CG meeting, 
> which
> I recorded and put online.
>
> M3fN2SQUcBQyhX6e.jpg
> Today I presented the @ietf's upcoming HTTPSig protocol (@http_wg) at 
> the @w3c Solid Community Group meeting. I illustrated it by running my 
> #scala crawler on #BigData published as #LinkedData #EventStreams 
> protected with #solidProject access control rules. This is about as…
> <https://twitter.com/bblfish/status/1666547828506742788>  
> The 🐠 BblFish <https://twitter.com/bblfish/status/1666547828506742788>
> twitter.com <https://twitter.com/bblfish/status/1666547828506742788>
>
> <https://twitter.com/bblfish/status/1666547828506742788>
>
> The in development spec, which I need to update is here:
> https://github.com/bblfish/authentication-panel/blob/sigUpdate/proposals/HttpSignature.md
>
> HTTP Sig requires a KeyID URL (which is compatible with the WebID URL and
> could be placed in the same document), eg as
>
> <#me>
>     foaf:name “Alice”;
>     cert:key <#k1> .
>
> <#k1> ….
>
> I am currently trying to tie this in with the security ontology.
>
> Compared to WebID-TLS:
>
> + It is much more flexible than client certificate negotation, allowing
>   each resoruce and mode to have its own rules and authentication proof.
> - it is not built into the browser (but we can do the signing via an 
> intermediary cache
>   and I have some ideas on how to do that in the browser)
>
> Henry
>

Hi Henry,

Bearing in mind that all modern computing devices already support TLS 
Client Certificate Authentication (CCA), how do you envisage the 
yet-to-be-invented intermediary cache you outlined being adopted on a 
scale anywhere close to what TLS CCA has already achieved?

You argue that HTTPSig is more flexible than Client Certificate 
Negotiation, but how can that be when its deployment is limited to the 
Fediverse where it's used for server-to-server exchange of ActivityPub 
payloads?

Most importantly, why not position HTTPSig as an additional option 
instead of attempting to present it in opposition to TLS CCA, which is 
certainly not going to be phased out anytime soon?

-- 
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