Server Side Credentials, IETF RG - Was: The UI part of credentials

The title of this thread was not quite right for this group. I should
have emphasized the importance of server side Verifiable Claims 
in this discussion on the Security Architecture Advisory Group of 
the IETF on "Stopping (https) Phishing"

https://mailarchive.ietf.org/arch/browse/saag/?gbt=1&index=FSF8WFvsCQRCRzsY6qlowmHlxy4

In answer to a question by Bret Jordan on how I see the way forward, I wrote quite
a few points, as this is a big project, but the following in particular is relevant to the 
Verifiable Claims Working Group:

[[
Caching: the point was raised and it is one that the security community is keen on that
the data should be able to come signed from the server one is connected to. In which case
it needs to be signed by the institution in the IWoT that serves it. Ideally the signed document 
could also be dereferenced, so that web sites can start simply by pointing to the institutions in
an http header or the X509 Cert, and when understanding the value optimise the process 
by serving something like what the Verifiable Claims WG is working on, but signed. 
There would then need to be an extension to the HTTP standard for passing the verifiable 
claim through, in addition to the X509 certificate. (I am assuming here that X509 is just going
to be a bit tedious to extend and teach. It would help if the data were the same in the Verifiable
Claim as the one that was served by the institution, so that the graphs are isomorphic)
]]
https://mailarchive.ietf.org/arch/browse/saag/?gbt=1&index=FSF8WFvsCQRCRzsY6qlowmHlxy4

They are now actually interested in starting a IETF Research Group on the topic!

Henry Story


> On 20 Jul 2018, at 12:18, Henry Story <henry.story@bblfish.net> wrote:
> 
> Hi all,
> 
>   I have been thinking a bit about servers and applications credentials recently
> which is the opposite of what I have been doing for a long time namely user 
> credentials. But since that also falls under Verifiable Claims, I thought you'd 
> be interested.
> 
>   Discussing this topic  in various forums one often
> finds one resistance to new ideas relating to the huge failure in the space of 
> user interfaces for this technology. Many have been burned by the many
> failures in that space. So I decided to address that problem with a 
> light weight and quite intuitive detour through modal logic. If you have ever 
> dealt with a salesman coming to your door, then you can follow the reasoning.... 
> This is then mapped to the UI problem where I came to the conclusion to my amazement 
> that there is actually a very useful cyber-security application for the 
> MacBook TouchBar! 
> 
> Phishing in Context
> Epistemology of the Screen
> https://medium.com/cybersoton/phishing-in-context-9c84ca451314
> 
> That follows up on a previous post 
> 
> "Stopping (https) Phishing"
> https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9
> 
> which shows that the problem with X509 server certs is the complete poverty of data that
> comes with it. So I make a case that one needs much richer Verifiable Server Claim 
> information if it is to be interesting to the user finding out about the web site 
> he is looking at. (or the app he is using) 
> 
> The flexible answer is to allow the browser to go online and fetch the information
> from the institutional web of trust. But the efficient one would be for the server
> to send a verifiable claim containing the same info and signed by the institution. 
> I think one could be flexible and allow both. But for that one would need very 
> flexible verifiable claims that could contain pretty much any data 
> (as shown in the example of info from Company House). So I think that means X509 is out
> long term. Then one could have Verifiable claims with 1 day time to live. 
> 
> So this may be an additional angle that can be useful to further the causes this group
> is interested in.
> 
> 
> Feedback welcome,
> 
> Henry Story
> 
>

Received on Tuesday, 24 July 2018 12:40:00 UTC