Re: RWW Use-Case Example: Web-Scale Ticketing Ideas from Kingsley Idehen on 2021-05-21 (public-rww@w3.org from May 2021)

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 21 May 2021 09:49:10 -0400
To: public-rww@w3.org
Message-ID: <e49ff90d-46fb-7a32-44ce-0703e16e943a@openlinksw.com>
On 5/21/21 3:17 AM, Henry Story wrote:
>
>> On 21. May 2021, at 02:44, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>> 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].
> Yes. There are ways to live with the situation.
> Of course with a browser extension you can do anything.
>
> There are a number of problems with X509 client Authentication over TLS
> that mean  that I think it does not quite fit our needs in Solid for hyper
> apps. For one, there is not much information the server can give out
> on what types of credentials are allowed, and X509 based as it is on ASN.1
> (ie. pre web, pre URLs) is not extensible in a decentralised way - you have
> to register numbers!!! Verifiable Credentials on the other hand is built
> on Linked Data principles so that is a **huge** step forward.


True, but I've always seen slotting a WebID into the SAN of an X.509 as
a mechanism for negating all of that i.e., move all the power to the
WebID-Profile doc where entity relationship type (relations) semantics
takeover.

In our eyes, at OpenLink Software, we simply look to ride the ubiquity
of X.509 and the superpowers of resolvable URIs.

If you put X.509 aside you lose on the "PasswordLess Authentication"
front i.e., what is the alternative to PKI (tweaked via URIs in SANs) in
that regard?


>
>>>> 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.
> I think we will have both. I am not yet quite sure what technology is around for user controlled credentials,
> But I guess browser plugins are likely the way to go there until uptake by browser vendors. There are quite
> a few other answers that need to be investigated.


Yes.


>
> Let us put in this way: User Controlled Credentials is the philosophy of Self Sovereign Identity.
> I recommend the Book on the subject by Manning that was just released, and I like the philosophy.
> The whole point of Verifiable Credentials is to be used the way X509 Certificates are used now.
> The user is meant to have a Wallet where he can store his Credentials. Same idea as the keychain.


Yes, and the ubiquity of Keychain (macOS), Keystore (Windows), and
PKCS#12 (if you want total control) is always important i.e.,
alternatives have to offer something that builds on ubiquity otherwise
its becomes another 10-20 year marathon (with unpredictable outcomes) re
mass adoption.


>
> Of course WebID and the technologies we are putting forward can fit that very well.
>
> Note that the version of the book from a few months ago contains a
> short section on WebID even. For some reason they presented WebID via the redirect version.
> I pointed that out, and it looks like instead of improving it, they decided to remove all references to
> WebID.
> Perhaps it is just a bit awakward that WebIDs are a form of DIDs that don’t need a new URI method?


Good catch!

I tend to look at it the other way around i.e., DIDs are WebIDs and
WebID-Profile docs conflated. If you understand WebIDs, you can work
with DIDs i.e., still bring the full power of logic as the conceptual
schema to bear; not necessarily so, if you start the journey from the
DIDs perspective -- IMHO.


>
>
>> 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 don’t think that that this is the direction the SSI folks are going for. For them it really is that Verifiable
> Credentials should be in your Wallet (a.k.a KeyChain).


True!

But I am skeptical about the ubiquity of wallets at the expense of
Keychain, Keystore, and PKCS#12.

I also believe strongly in having the WebID-Profile Doc controlled by a
user as the focal point of Credentials Management.

Anyway, we are a point where all of these approaches can co-exist if
practitioners enhance their understanding of URIs and the important role
of logic as the universal conceptual schema.


>
>
>>> 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.
> yes. I just think we can move step by step towards the big picture
> learning from the experience gained by doing so.


Yep!


Kingsley

>
>>>
>>>> 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
>>
>>
>>
> 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
Received on Friday, 21 May 2021 13:49:28 UTC