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

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

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

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.

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?


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


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

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