Re: HTTPSig authentication

On 6/14/23 6:45 AM, Henry Story wrote:

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

Neither do I. The question is: how will compatibility be achieved, 
unobtrusively?

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

Personally, I don’t see anything wrong with that. You have roads (where 
TLS operates) and transportation vehicles (where Apps operate) the issue 
at hand boils down to identity authenticity of the vehicle driver (i.e., 
person described by notarized credentials in a driver’s license).

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

Any links to such docs?

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

I disagree, in line with the example I made above, regarding the 
driver’s license holder :)

​

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