Re: DIDs, DID Auth & Browser Cookies

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

On Wed, Mar 21, 2018 at 2:11 PM, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca
> wrote:

> Yes I also think these are separate concerns basically.
> DID Auth has to do with authentication between entities. You can look at
> some of the work being done by the community here … https://github.com/
> WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/
> master/draft-documents/did_auth_draft.md .. .there are links within that
> doc to other topic papers and so forth.
> The BC Gov has funded some open source early implementations which can be
> found here … https://github.com/search?q=org%3Abcgov+did
> Cookies are a browser (HTTP) specific construct to maintain session. So
> tracking mechanisms based on cookies would still work. I think social and
> regulatory change will be the forces that shape how and what is tracked.
> Perhaps new more privacy enhancing options will emerge for these kinds of
> abilities.
>
> J
>
>
> From: Christian Lundkvist <christian.lundkvist@consensys.net>
> Date: Wednesday, March 21, 2018 at 6:36 AM
> To: Dennis Yurkevich <dennis@mediaiqdigital.com>
> Cc: =Drummond Reed <drummond.reed@evernym.com>, "Jordan, John CITZ:EX" <
> John.Jordan@gov.bc.ca>, "public-credentials@w3.org" <
> public-credentials@w3.org>
> Subject: Re: DIDs, DID Auth & Browser Cookies
>
> Hi Dennis,
>
> Personally I think your question is valid and I think session cookies is a
> reasonable solution for maintaining a browser session in the short term.
> I.e. you “log in” first with DID Auth, the service associates your DID with
> a browser cookie and as long as the cookie is valid your session is
> maintained.
>
> Another model could be to generate another private key in the browser,
> associate this with your DID at the service and then sign every request
> with the browser key.
>
> You can still require a separate DID Auth with the users phone/edge device
> when authorizing high-value transactions.
>
> Christian
> On Wed, Mar 21, 2018 at 10:45 AM Dennis Yurkevich <
> dennis@mediaiqdigital.com<mailto: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
>
> On Wed, Mar 21, 2018 at 4:38 AM, =Drummond Reed <drummond.reed@evernym.com
> <mailto:drummond.reed@evernym.com>> wrote:
> +1 to John's reply. DIDs essentially inverse the traditional cookie
> relationship, i.e., rather than a site handing you a cookie (over which you
> have no control other than to delete it), you hand the site a DID. Because
> you control the private key, you can always prove control of that DID. You
> can even rotate the public/private key pair associated with the DID and
> still prove control.
>
> That's why they are sea change in both identification and authentication
> (and, in conjunction with verifiable credentials, in authorization as well).
>
> =D
>
> On Tue, Mar 20, 2018 at 5:08 AM, Jordan, John CITZ:EX <
> John.Jordan@gov.bc.ca<mailto: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
>
> On Mar 20, 2018, at 05:06, Dennis Yurkevich <dennis@mediaiqdigital.com<
> mailto:dennis@mediaiqdigital.com><mailto:dennis@mediaiqdigital.com<mailto:
> dennis@mediaiqdigital.com>>> wrote:
>
> Hello All,
>
> I have quite a general question on which I am yet to find an answer
> anywhere on the github repo.
>
> How does this group see DIDs and specifically DID Auth interacting with
> traditional browser cookies, specifically my questions are:
>
>   *   If a user checks the "remember me" button on a site which uses DID
> Auth, what would be the implementation flow?
>   *   In the scenarios where a site uses various third party analytics
> systems which set tracking cookies, is there a better way to do this using
> DIDs?
>
> Thanks!
> Dennis
>
> --
> [Vital Design]<http://www.mediaiqdigital.com/>
> Dennis Yurkevich
>
> 5th Floor | High Holborn House | 52-54 High Holborn | London | WC1V 6RL<
> https://maps.google.com/?q=52-54+High+Holborn+%7C+
> London+%7C+WC1V+6RL&entry=gmail&source=g>
> dennis@mediaiqdigital.com<mailto:dennis@mediaiqdigital.com><mailto:dennis@
> mediaiqdigital.com<mailto:dennis@mediaiqdigital.com>>
> tel +44 (0)20 700 0420 | mobile +44 (0) 7794 597783
> <tel:%2B44%20%280%29%207794%20597783>
> [Twitter]<http://www.mediaiqdigital.com> [Blog] <https://www.facebook.com/
> MediaiQDigital>  [Facebook] <https://twitter.com/mediaiqdigital>
> [LinkedIn] <https://www.instagram.com/mediaiqdigital>  [Foursquare] <
> https://www.linkedin.com/company/media-iq-digital-ltd>  [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
>
>
>
>
> --
> [Vital Design]<http://www.mediaiqdigital.com/>
>
> Dennis Yurkevich
>
>
> 5th Floor | High Holborn House | 52-54 High Holborn <
> https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%
> C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g> | London <
> https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%
> C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g> | WC1V 6RL<
> https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%
> 7C+%C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g>
> dennis@mediaiqdigital.com<mailto:dennis@mediaiqdigital.com>
> tel +44 (0)20 700 0420 |<https://maps.google.com/?q=
> 52-54+High+Holborn%C2%A0+%7C+%C2%A0London%C2%A0+%7C+%C2%
> A0WC1V+6RL&entry=gmail&source=g> mobile +44 (0) 7794 597783
>
>
>
> [Twitter]<http://www.mediaiqdigital.com/> [Blog] <
> https://www.facebook.com/MediaiQDigital>  [Facebook] <https://twitter.com/
> mediaiqdigital>  [LinkedIn] <https://www.instagram.com/mediaiqdigital>
> [Foursquare] <https://www.linkedin.com/company/media-iq-digital-ltd>
> [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 |<
> https://maps.google.com/?q=52-54+High+Holborn%C2%A0+%7C+%
> C2%A0London%C2%A0+%7C+%C2%A0WC1V+6RL&entry=gmail&source=g> Company Number
> 07321732 | VAT No: GB995910763
>
>
>