Stream: social
Topic: Good ol' blockchain
James Agnew (Feb 14 2020 at 11:29):
I just love this advertorial-disguised-as-article running in forbes: https://www.forbes.com/sites/richardgendalbrown/2020/02/13/the-five-ingredients-of-blockchain-interoperability/#5adfb2a058a1
2020 is finally blockchain's year!
If you're "in the trenches" you probably don't understand what I mean!
Now we have interoperability problems too!
Oh yeah, those interoperability problems are all basic transport level problems you only have because you're using blockchain!
(Ps I sell software that solves those problems)
David Pyke (Feb 14 2020 at 14:18):
Blockchain is the source AND solution for all today's problems! You aren't 100% buzzword compliant without one!
David Pyke (Feb 14 2020 at 14:29):
I suppose we need a blockchain node resource now.
John Moehrke (Feb 14 2020 at 14:35):
We are blockchain buzzword compliant. We have a #blockchain stream
Chris Moesel (Feb 14 2020 at 15:01):
Obligatory XKCD: https://xkcd.com/2267/
Blockchains are like grappling hooks, in that it's extremely cool when you encounter a problem for which they're the right solution, but it happens way too rarely in real life.
Brendan Keeler (Feb 14 2020 at 16:18):
Fun to rip on blockchain. Have a draft blog about the topic from a while ago but shelved it due to it not being a good solution for most healthcare problems seeming to be the common sentiment.
I'd love to hear/read something by a blockchain bull that expresses their conviction without selling their product.
To me, it has no distinct advantages over legacy solutions for edge interfacing in an enterprise. I could see limited applicability in lightweight concepts like consent or patient identity being conveyed across enterprises using blockchain, but not enough of a level up over trusted exchange networks. For patient auth, I don't see advantages over existing SMART on FHIR.
Brendan Keeler (Feb 14 2020 at 16:18):
Although perhaps I should be grateful. Blockchain netted me my most popular tweet by a long shot
https://twitter.com/BrendanRedox/status/1189919553368670214?s=19
I talked to a healthcare startup today. No AI. No blockchain. No augmented reality. They just sat there. Providing value to patients and providers. Like a psychopath.
- Brendan Keeler (@BrendanRedox) Dave deBronkart (Feb 14 2020 at 20:54):
That tweet sounds like a (for real) description of Direct Primary Care, actually.
James Agnew (Feb 14 2020 at 21:43):
ahaha i am now subscribed to #blockchain
Josh Mandel (Feb 14 2020 at 22:15):
I have a use case for self-owned identity that sometimes involves blockchain. https://twitter.com/JoshCMandel/status/1228002037289357317 is a write-up I shared yesterday. (Well, "write-up" is the wrong word for a video...)
Healthcare's riddled with challenges in identity, authentication, privacy. Issues so fundamental they can be hard to spot. In https://www.youtube.com/watch?v=LEfgVrzwipw I point them out + directions for improvement (spoiler: "self-owned" identity standards). I'd love feedback!
- Josh Mandel (@JoshCMandel) Grahame Grieve (Feb 15 2020 at 05:10):
the primary application of block chain is to separate investers(/fools) from their money
but there's a useful secondary application that blockchain can solve all your interoperability problems.
Grahame Grieve (Feb 15 2020 at 05:11):
the way this works is that mgmt is finally so invested in digital exchange that they actually have to invest in solving all the problems that prevent the technical solutions.
Presto- block chain solves interoperability!
Brendan Keeler (Feb 15 2020 at 06:53):
(deleted)
Brendan Keeler (Feb 15 2020 at 06:53):
Screenshot_20200214-225224.png
Brendan Keeler (Feb 15 2020 at 06:53):
It's a rocketship Grahame
Brendan Keeler (Feb 15 2020 at 06:53):
selectively chooses period that reinforces my hypothesis
Grahame Grieve (Feb 20 2020 at 02:39):
it seems odd to me to make 'what protections should be placed on your account' as part of authentication
Grahame Grieve (Feb 20 2020 at 02:57):
@Josh Mandel looking at the bigger picture... is there anything we should do to move this forward?
Josh Mandel (Feb 20 2020 at 02:58):
2FA is a kind of protection, and also a kind of authentication -- that was my intention anyway.
Josh Mandel (Feb 20 2020 at 02:59):
I've been thinking about that :-) I'm not sure what the best place to make a dent is right now. It seems like technology that's not quite there yet for a broad audience of consumers, but maybe something like using it for app developer identity proofing to get elevated trust around applications would be a good fit.
Grahame Grieve (Feb 20 2020 at 02:59):
most countries will watch that in incomprehension and say that this is an obvious thing for login.gov to handle. but not alll
Grahame Grieve (Feb 20 2020 at 02:59):
maybe something like using it for app developer identity proofing to get elevated trust around applications would be a good fit.
That's not a problem we take on though?
Josh Mandel (Feb 20 2020 at 03:00):
I'm very open to ideas / brainstorming here, and it's something my team is interested in spending more time and effort on as well.
Grahame Grieve (Feb 20 2020 at 03:00):
Is there anything we'd do in smart-app-launch around this? it's all further back, right?
Josh Mandel (Feb 20 2020 at 03:00):
Well, "we" with our FHIR hats on maybe not, but it's tightly knit, and this is the social channel after all :-)
John Moehrke (Feb 20 2020 at 03:01):
to SMART all modes of user authentication are possible, usually by way of OpenID-Connect
Josh Mandel (Feb 20 2020 at 03:02):
Yeah, it's not necessarily an app launch time kind of thing -- but for example, a security specification that involved personal identity hubs holding consents, causing a FHIR server to release data based on their contents... That's a fun spin on UMA.
John Moehrke (Feb 20 2020 at 03:02):
that is what HEART did with UMA
Grahame Grieve (Feb 20 2020 at 03:02):
so we've never taken on the identity link problem. we just ignore it. maybe we should?
Josh Mandel (Feb 20 2020 at 03:03):
Minus the personal data hub and DID infrastructure. Different tech, some of the same goals
John Moehrke (Feb 20 2020 at 03:03):
unfortunately no one can resolve the trust issues with HEART... why would the user trust a HEART server, why would a provider be able to trust a HEART server... so wonderful tech, no possibliliyt to succeed
Josh Mandel (Feb 20 2020 at 03:03):
That's an interesting point. Patient-authorized links or somesuch
Grahame Grieve (Feb 20 2020 at 03:03):
they can run their own ;-)
Grahame Grieve (Feb 20 2020 at 03:03):
but trust has to be somewhere.
John Moehrke (Feb 20 2020 at 03:04):
yup,.. huge number of patients can run their own HEART server
Josh Mandel (Feb 20 2020 at 03:04):
Here the trust would come from a shared decentralized identity system, and nonrepudiabiable consent claims.
John Moehrke (Feb 20 2020 at 03:04):
that doesn't solve the trust issue.. just makes it move to a different location... tech is not the solution
Josh Mandel (Feb 20 2020 at 03:05):
Doesn't matter what server is running, If we can tell that the permissions originated from the patient based on a private key that only they control in their digital wallet, etc. All that jazz
Josh Mandel (Feb 20 2020 at 03:05):
At that point, the trust comes from a health system having a relationship with the individual.
John Moehrke (Feb 20 2020 at 03:05):
lookup SQRL - https://www.grc.com/sqrl/sqrl.htm
Josh Mandel (Feb 20 2020 at 03:06):
I like the direction you were thinking in Grahame around What we could say about linking identities.
John Moehrke (Feb 20 2020 at 03:06):
Josh Mandel said:
At that point, the trust comes from a health system having a relationship with the individual.
that is the only one that works today
Josh Mandel (Feb 20 2020 at 03:06):
We might be able to develop a profile on top of the DID stuff for this.
John Moehrke (Feb 20 2020 at 03:06):
and it works because POSTAL-MAIL is used to initialize the trust, and POSTAL fraud is a big hammer
Josh Mandel (Feb 20 2020 at 03:07):
But it's a super neat technical trick to take that direct organization to patient trust, and still allow a third-party server to come in and mediate the interaction without having to trust that server with the keys to the kingdom.
Grahame Grieve (Feb 20 2020 at 03:07):
right. we're not going to take on managing identity etc, but at some stage we need to do something about linking into those systems
John Moehrke (Feb 20 2020 at 03:07):
so does DID have a OpenID-Connect impl?
John Moehrke (Feb 20 2020 at 03:07):
how do you prevent me from masquerader as YOU
Josh Mandel (Feb 20 2020 at 03:07):
There's a DID auth spec based on OpenID SIOP, yes.
John Moehrke (Feb 20 2020 at 03:08):
so then we are done
Josh Mandel (Feb 20 2020 at 03:08):
https://identity.foundation/did-siop/
John Moehrke (Feb 20 2020 at 03:08):
:-)
Josh Mandel (Feb 20 2020 at 03:08):
That does not get at the interesting details about which links a patient wants to authorize
Josh Mandel (Feb 20 2020 at 03:08):
It's just a sign in protocol
John Moehrke (Feb 20 2020 at 03:08):
pluggable security standards are wonderful
Josh Mandel (Feb 20 2020 at 03:08):
A way to convey an identifier but not details about the identity
John Moehrke (Feb 20 2020 at 03:08):
yes the identity binding is still needed. and DID isn't going to help that
Josh Mandel (Feb 20 2020 at 03:09):
No I think that's exactly why verifiable credentials and verifiable presentations are brilliant.
John Moehrke (Feb 20 2020 at 03:09):
Note that there have been proposals within Security WG for a "Provisioning" resource
John Moehrke (Feb 20 2020 at 03:09):
might be a Task like resource... not much has happened around the concept
John Moehrke (Feb 20 2020 at 03:12):
the non-linkability-of-identity functionality of DID has been around in SAML for a long time, although the identity provider does know all, the relying parties would get non-linkable service unique identity... no one uses it... but lots of people like to say it is critical
Josh Mandel (Feb 20 2020 at 03:14):
Here the point though is that there is no master identity provider in the loop. nobody who gets to track you everywhere you go and learn about every place you sign into. You can just share whatever attributes about your identity you want to in the context of any specific interaction.
John Moehrke (Feb 20 2020 at 03:27):
yes, and I suspect that we are entering an environment where there will be compelling demand to make it real, where past (SAML) has not had compelling demand
John Moehrke (Feb 20 2020 at 03:27):
just pointing that out.
John Moehrke (Feb 20 2020 at 03:27):
note that SQRL has that function too
John Moehrke (Feb 20 2020 at 03:28):
so the function is available in many identity authentication assertion models... it just needs to be complling enough to drive use vs the burden it presents (difficult to use and easy to messup)
John Moehrke (Feb 20 2020 at 03:30):
watched your youtube video.. nice note on Consent Receipt. I worked on that, and continue to be connected. They are moving even beyond that simple model. But the simple model is 'simple' yet powerful
John Moehrke (Feb 20 2020 at 03:31):
everything you mention is good solid stuff.. stuff that I think we have good hooks for in the fhir security pages, including something explicitly mentioned there. other stuff a bit less mature, but as you indicate well worth some attention to help it evolve.
Josh Mandel (Feb 20 2020 at 03:32):
When you say "the function" I'm not sure what this means. I think there's a constellation of desirable functions including the ability for individuals to present selected attributes of their own identity without an authoritative server in the loop; the ability to sign in using cryptographically key materialin the individual users control; the ability for anyone to play the role of a relying party, a presenting party, and even of an issuer.
Josh Mandel (Feb 20 2020 at 03:33):
I'm not sure any of the other technologies you are listing here offer this constellation of functionality.
Josh Mandel (Feb 20 2020 at 03:33):
To be clear, I agree that the FHIR security page has plenty of hooks :-)
John Moehrke (Feb 20 2020 at 03:47):
much of what you have talked about in the video is meat-and-potatoes in the security realm. Identity, Authentication, etc... that is what I mean. I realize much of the talk had to set the stage for the last slide... I am just agreeing with your background and hoping that you agree that we already include meat-and-potatoes... with that agreement, we can move to solutions space. which I think is your intention of the last slide... right?
John Moehrke (Feb 20 2020 at 03:48):
plenty of experimentation and alternatives to play with. but how they integrate with standards is with security layering
Grahame Grieve (Feb 21 2020 at 20:49):
relevant: https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html
Josh Mandel (Feb 21 2020 at 21:43):
Yes! This is the "personal hub" vision.
Grahame Grieve (Feb 21 2020 at 21:45):
would we need to do anything to make this happen for FHIR data?
Josh Mandel (Feb 21 2020 at 22:50):
I'm not sure -- poke at it, build a "fetch-and-forward" app, and see if there are surprises.
Josh Mandel (Feb 21 2020 at 22:54):
This version of the authorization user interface (node-solid-server V5.1) only supports the toggle of global access permissions to all of the data in your Pod.
That feels familiar ;- )
Patrick Haren (Feb 22 2020 at 03:21):
I love the discussion, but what I still have a hard time figuring out is how any of this gets away from the need for probabilistic matching or some sort of trusted authority on the linking of trustable identities (and associated data). Are we saying that, if the consumer can overcome the blank slate on a relationship, they can then be trusted to provide the PIX-like links (via their personal hub)?
Patrick Haren (Feb 22 2020 at 03:21):
If we have trustable, decentralized identities by themselves, there’s still not anything that says that this trustable identity corresponds the this singular thing with a belly button, across the interactions that we have with them. Or is there?
René Spronk (Feb 22 2020 at 09:26):
I think it's worth exploring. Not just because we may like the underlying principle as put forward by Tim BL, but also of an example of how one can use FHIR in a fully distributed manner. That aspect IMHO hasn't been given sufficient attention as of yet in the FHIR community.
David Pyke (Feb 22 2020 at 15:24):
I"m all for this, the key to all of it would be the Consent resource but searching for the necessary permission pair on each access would be a huge overhead.
Jose Costa Teixeira (Feb 22 2020 at 16:20):
Consent? As in patient-granted specific consent?
David Pyke (Feb 22 2020 at 16:31):
Yes, the whole model is having an individual grant specific consent for device/program pairs.
Josh Mandel (Feb 22 2020 at 16:39):
Yes the only route that I know to move away from probabilistic matching is to put patients in control of deciding which links they want to assert, based on explicit sharing of identity attributes or data pointers. To be clear, I don't think this is going to make the probabilistic matching networks go away, but I think it will provide a complementary set of channels to move health information around, with nicer properties.
Jose Costa Teixeira (Feb 22 2020 at 16:52):
Also here, I don't understand why patient-granted Consent is our token for permissions. Poor patients.
Patrick Haren (Feb 22 2020 at 16:56):
I think there might be an interesting novel concept here. Let’s say the patient owns their own PIX. If we can establish mechanisms to trust the full (decentralized) PIX that they control, we would have a built-in way to support patient consent AND precise matching – i.e. by providing their PIX, any organization that the patient has consented to provide access, then has the PIX and consent to query for records with deterministic identifiers (e.g. system-specific MRNs). You would still need to support the “patient unconscious on stretcher” scenario – some sort of “breaking glass” access to their PIX – such as the classic life alert, or an ICE function on smartphone.
Patrick Haren (Feb 22 2020 at 16:56):
@Jose Costa Teixeira yes, it. would not be paternalistic healthcare, but that's the idea.
Jose Costa Teixeira (Feb 22 2020 at 16:59):
If we have a central government and several regional governments, each capable of granting permission (not consent, the patient has no idea what is happening behind the scenes) and each with a health vault you have the same situation.
Jose Costa Teixeira (Feb 22 2020 at 17:00):
I guess that is the point. I don't think we have "consent-granted acces or break the glass scenario". I think we have consent-granted, break the glass, and legally authorized access to data.
Jose Costa Teixeira (Feb 22 2020 at 17:00):
I am just arguing against patient consent to be the key
Patrick Haren (Feb 22 2020 at 17:04):
yep. maybe patient consent can help facilitate or streamline the legally authorized access where the legal orgs (like under HIPAA in US) still have a tough time figuring out identities across systems (since there are no universal ids shared across systems).
Abbie Watson (Feb 22 2020 at 17:54):
Josh Mandel said:
Yes! This is the "personal hub" vision.
Exactly what Symptomatic has been working on with the Meteor on FHIR build, and later the Node on FHIR build. I really like this 'personal hub' branding that seems to be emerging in a few quarters. It's the logical culmination of miniaturizing EHR tech onto a phone, but we haven't had good language for it. But awareness that these things seems to be growing, happily.
Grahame Grieve said:
would we need to do anything to make this happen for FHIR data?
If you actually want Tim Berner's-Lee approach, we could drop the Solid server library into the Node on FHIR build easily enough. With the Switchboard and Smart on FHIR modules, we'd have the basics of a distributed Solid on FHIR network. Would need 40 to 80 hours of work to get the "Hello Mesh" prototype working, plus at least three participants running hubs. After that, 160 to 240hrs of UI design work for workflow, which is about what was needed for the hyperledger pilot.
https://www.npmjs.com/package/solid-server
Abbie Watson (Feb 22 2020 at 17:58):
I have been thinking of a similar architecture using IPFS, with the intent of standing up a bit-torrent like network but without smart contracts. Just a way to share configuration information among a swarm of devices. Easier said than done, but we've gone through a half-dozen prototypes and are closing in on a final production release.
Anyhow, as far as I can tell, Solid is similar to IPFS, with the key difference (in my opinion) being that Solid supports WebID/OpenId and Semantic Web.
Adam Flinton (Mar 02 2020 at 12:56):
NHS is looking @ sovrin e.g. https://www.windley.com/archives/2016/10/how_sovrin_works.shtml https://sovrin.org/
Last updated: Apr 12 2022 at 19:14 UTC
