Re: DIDs, DID Auth & Browser Cookies

On 20 March 2018 at 14:08, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca>
 wrote:

> Hi Dennis
>
> There are deeper experts here however my thinking is there is no more
> “remember me” as there will no longer be a “login”.  One will simply
> connect to a service at which point DID Auth will occur. You will already
> be authenticated via the device you are using to control your private keys.
> Ideally DIDs are pairwise unique so I guess a site could use your DID for
> preferences and so forth.
>
> Remember me and cookies a hack to solve user experience issues around user
> logon and sessions.
>
> Not sure what to say about tracking. I think there needs to be consent and
> withdrawal of consent at least :) ... maybe DIDs can help with user control
> of consent.
>
> J



I have to agree with John, the browser / cookies / session / HTTP and for
that matter E-mail client / GIT client / Jabber client / Mobile phone / etc
are all out of scope for the specification / documentation.

What we might want to iterate is that DIDs should be recognised by our
client software just like they currently do for Personal SSL certificates
and needs to be added to key chain.app or the list of certificates in
firefox for example.

As far as I understand DIDs will work just like PKI and actually handshake
with the server (HTTPS, SMTPS, POP3S, IMAPS)  software to now encrypt (and
digitally sign) all data sent to the server just like all data received are
currently secured by server certs.

These interfaces are already in place but the client software (browser,
mail client, etc) will need to understand the DIDs (are like personal SSL
certs) and that they have a CA (certificate authority) which is the
"distributed identity ledger"(is this the correct name?) and that this CA
(DID server) is to be trusted.

Another thing worth mentioning, if DID is recognised as a cert in your
e-mail client, we would finally be able to send peer to peer encrypted mail
from DID to DID as well. This too is build, tested, ready and waiting for
us to use, all we need is to have DIDs recognised as PKI personal certs as
issued by the ledger as CA.


On 21 March 2018 at 11:41, Dennis Yurkevich <dennis@mediaiqdigital.com>
 wrote:

> Thank you Drummond and John for your replies.
>
> I understand the concept and benefits of DID auth, however I am more
> thinking of how this can be implemented in the short term as websites will
> not (most likely) switch over from current auth workflow to DIDs all at
> once, and they will want to cater for users who do not have capability to
> authorise using DIDs.
>
> But lets say I am using my mobile device on which I have stored my *privK*,
> to authenticate on a website. If we say take the uPort approach and show a
> QR code to facilitate this - what happens if I shutdown my browser
> (accidentally) and want to log back in? Does this group feel that
> implementers will still be forced to use session cookies?
>
> And the second question still stands, many people are using cookie based
> tracking and analysis in their apps - what do you envisage companies such
> as this with no direction user interaction would do?
>
> I think these are important questions (and many more) when we think about
> the DID auth spec to ensure we capture real world use cases in such a way
> adoption possibility is increased.
>
> Best,
> Dennis
>

To gain access to the DID certificate (identity) information the web sites
will query their web severs (NGinx, Apache) to retrieve the information
from the back end. If I recall you cannot use vanilla JavaScript to query
the browser for the certificates but there may be some ways around this
with external libraries. None of this will effect the way current websites
have there sites configured (with or without cookies, sessions etc) all we
are doing is removing the need for log in (and remember me).

If you are concerned with on-boarding then we could hack together some
widgets and script libraries to help cross the transition in the beginning.
I don't feel this is something that needs to go into the spec as it will
only be for the interim.
But if the browser does not recognise the DID as a PKI cert to secure the
request/response channels with, well then we have a white elephant.


On 21 March 2018 at 17:32, Topper Bowers <topper@quorumcontrol.com> wrote:

> I just want to reiterate the last statement. In building key-based systems
> I've learned to keep appreciating the cookie :). Also.... new systems work
> really well with OpenID Connect as well. That allows apps to speak one
> thing, but change how auth is done in a single place. When I've been
> marketing my alternative ACL system, having an openid endpoint really goes
> a long way to convincing people that "hey, we can actually use this today.."
>
> No need to reinvent every part of identity from the very beginning.
> Starting with strong key-based authentication with revocation and
> credentials is *huge*.
>

OpenID would probably choose to recognises DID as an identity and be
willing to use it to authenticate with which would be awesome!!
Before that happens if you simply configure openID for authentication then
we are not using DID as it will expect an OpenID identity. Here is more
info on that: https://youtu.be/Kb56GzQ2pSk

  nickl