Re: RWW Use-Case Example: Web-Scale Ticketing Ideas

On 5/20/21 1:47 PM, Henry Story wrote:
>
>> On 20. May 2021, at 19:28, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>> On 5/20/21 11:22 AM, Henry Story wrote:
>>>> On 20. May 2021, at 17:17, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>>
>>>> Changed title to orient focus.
>>>>
>>>> Here's what exists currently, putting blockchains aside.
>>>>
>>>>  • I can generate an X.509 Certificate (which an expiration date) that functions as my Web Ticket
>>>>  • I can ACL protect my RDF documents and even associated services
>>>> Adding a blockchain to the mix solves the following:
>>> Btw. with Verifiable Credentials we should now be in a position to go beyond X509 - finally!
>>> It is also quite possible to bypass the TLS layer for authentication.
>>> Finally one can use description logic to describe access rights.
>>>
>>> I am trying to bring all these ideas together here:
>>>
>>> https://github.com/solid/authentication-panel/blob/main/proposals/HttpSignature.md
>>>
>>> One type of description could be ownership of a ticket, signed by the agency giving out the tickets.
>>
>> Okay, but don't loose track of the following PKI virtues:
>>
>> 1. TLS ubiquity -- supported by every modern OS
> HTTP Sig relies on TLS.
> It’s just that we don’t rely on client certificate authentication in TLS.


Okay, so TLS Client Certificate Authentication (CCA) is negated -- which
is also the perceived source of UX headache re WebID-TLS.


>
>> 2. X.509 ubiquity -- ditto
> It will clearly take a very long time for X509 to go away.


I doubt it will ever go away i.e., has become critical infrastructure
hence its support across all modern operating systems.


>
>> 3. PKCS#12 ubiquity -- ditto
> yes.
>
>> Alternatives that exclude the items listed above will inherit
>> significant "ubiquity attainment" opportunity costs, IMHO.
> The use cases for Verifiable Claims are very different, and mostly on the
> client side. Client Side auth with TLS has been pretty much deprecated
> by Chrome when they removed the <keygen …> html element from the browser.


I wouldn't really frame it that way re <keygen/>. Remember, that's
simply about credentials generation which has now been replaced by Web
Crypto implemented as a library across all the major browsers i.e., You
can generate a keypair from the browser in a user-friendly way. We even
offer an extension that does that [1].


>
>> We will certainly add support for HttpSignatures to our stack, but I am
>> concerned about bootstrap, on-boarding, and user experience.
> It is still in development. Now, I did implement something very similar about
> 5 years ago with a previous version of Signing HTTP Messages.


Yes, I am aware of that :)


>
> What is new is that Signing HTTP messages is now worked on at the IETF HTTP Bis
> working Group, that Verifiable Credentials is a standard, (though the signing part
> is going to be standardized next) and the use of OWL description logics for attribute
> based access control.


That's all good, but I am still concerned about an important issue re
the nature of credentials i.e., are these credentials user or
application controlled. *
*

*User Controlled Credentials Situation Example*

1. X.509 Cert and associated Private Key

2. Items above stored to a user's Keystore (e.g., Keychain on macOS or
equivalent on Windows) or a PKCS#12 file

A user is fully aware of the above, in regards to credentials and their
use for authentication using various authentication protocols.

*Application Controlled Credentials Situation Example*

1. JWT replaces X.509 Cert

2. CStorage is to a Browser's Storage (e.g., across cookies, local
storage, session storage, and even the more recent token storage feature)

A user is typically oblivious to these credentials i.e., applications 
control the flow of credentials, somewhat surreptitiously .


>
> I think one can easily get something like WebID-TLS going and simple attribute based
> access control done quite quickly, while the other standards get finished, and
> we learn from the experience of building up apps and servers that use it.


Sure, but the issues I raise above are very important.


>
>
>> BTW -- have you been tracking DPKI [1] ?
> No, I had not. But thanks for pointing it out to me. It looks like it is
> something I can wait to see how it evolves… :-)


Okay.


Links:

[1]
https://chrome.google.com/webstore/detail/openlink-youid/kbepkemknbihgdmdnfainhmiidoblhee?hl=en
-- quietly released for now

[2]
https://security.stackexchange.com/questions/128185/jwt-vs-client-certificates
-- JWT vs X.509 Client Certificate


Kingsley

>
>> Links
>>
>> [1] http://www.weboftrust.info/downloads/dpki.pdf -- DPKI
>>
>>
>> Kingsley
>>
>>>>  • Making my Ticket more copy-proof by tracking ownership via a Blockchain -- rather than depending solely on "private key" access and control on the part of users
>>>>  • Handling accounting for future royalties etc
>>>> Links:
>>>>
>>>> [1] https://medium.com/virtuoso-blog/understanding-our-lod-connectivity-license-offer-2eef8fffaa7e -- example of the X.509 approach that's been in use for a while now re ODBC and JDBC Connectivity to the LOD Cloud
>>>>
>>> Henry Story
>>>
>>> https://co-operating.systems
>>> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
>>> Twitter: @bblfish
>>>
>> --
>> 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
> Henry Story
>
> https://co-operating.systems
> WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
> Twitter: @bblfish
>

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