Re: DIDs, DID Auth & Browser Cookies

Thanks Nick & Dave.

Agree with all of what you have said, I was not aware of the IETF token
binding spec - this looks very interesting and would simplify this process
greatly.

Best,
Dennis

On Wed, Mar 21, 2018 at 10:51 PM, nickl <w3c@jigsoft.co.za> wrote:

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



-- 
[image: Vital Design] <http://www.mediaiqdigital.com/>
Dennis Yurkevich
5th Floor | High Holborn House | 52-54 High Holborn | London | WC1V 6RL
dennis@mediaiqdigital.com
tel +44 (0)20 700 0420 | mobile +44 (0) 7794 597783
[image: Twitter] <http://www.mediaiqdigital.com> [image: Blog]
<https://www.facebook.com/MediaiQDigital> [image: Facebook]
<https://twitter.com/mediaiqdigital> [image: LinkedIn]
<https://www.instagram.com/mediaiqdigital> [image: Foursquare]
<https://www.linkedin.com/company/media-iq-digital-ltd> [image: Pinterest]
<http://www.mediaiqdigital.com/inspirethroughinsights>
*Disclaimer: *This email and its attachments may be confidential and are
intended solely for the use of the individual to whom it is addressed. Any
views or opinions expressed are solely those of the author and do not
necessarily represent those of Media iQ Digital Limited. If you are not the
intended recipient of this email and its attachments, you must take no
action based upon them, nor must you copy or show them to anyone. No
contracts or official orders shall be concluded by means of this email.
Please contact the sender if you believe you have received this e-mail in
error.

Media iQ Digital Limited is a company registered in England and Wales |
Company Number 07321732 | VAT No: GB995910763