Re: HTTPSig authentication

> On 13. Jun 2023, at 19:00, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 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.
>> 
>> 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?
> 
I don’t think HTTPSig and client cert authentication are incompatible. It is just that as it
stands TLS Client cert is less flexible because it works at the connection layer rather than
at the Application Layer (in this case HTTP). 

I have seen proposals put forward to allow the HTTP layer to ask for client cert renegotiation at the TLS layer. But I am not sure where that ended up going to.

Because TLS client auth is over the whole connection, you can’t use one claim for one resource and another one for another one. 

> -- 
> Regards,
> 
> Kingsley Idehen       
> Founder & CEO 
> OpenLink Software   
> Home Page: http://www.openlinksw.com <http://www.openlinksw.com/>
> Community Support: https://community.openlinksw.com <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 <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
>