Stream: implementers
Topic: Subscription Connectathon Stream
Grahame Grieve (Nov 02 2016 at 20:28):
so there's going to be a connectathon stream around the subscription resource in January, and it's already being worked on....
Grahame Grieve (Nov 02 2016 at 20:28):
It's raised a question for me:
Grahame Grieve (Nov 02 2016 at 20:28):
the websocket documentation says:
Grahame Grieve (Nov 02 2016 at 20:29):
Client authenticates to server using a server-specified Web socket protocol (e.g. OAuth bearer token presentation)
Grahame Grieve (Nov 02 2016 at 20:30):
just so we're clear about this: do we think that the server should OAuth on the the main end-point, and then use the same protocol? or do we think that the OAuth should occur on the web socket end-point?
Grahame Grieve (Nov 02 2016 at 20:30):
I don't know what that would even mean....
Grahame Grieve (Nov 02 2016 at 20:30):
@Josh Mandel @James Agnew @Praveen Ekkati @Claude Nanjo .. comments?
Grahame Grieve (Nov 02 2016 at 22:59):
more on this: then we say:
Grahame Grieve (Nov 02 2016 at 22:59):
Server sends a "ping :id" message to notify the client each time a new result is available
Grahame Grieve (Nov 02 2016 at 23:00):
if you can only subscribe to a single :id (that's what we imply, but not actually what we say explicitly) then why send :id?
Grahame Grieve (Nov 02 2016 at 23:00):
can we also change it so that if you specify a payload type, then you get ping {resource}
Simone Heckmann (Nov 03 2016 at 10:48):
(deleted) I read the meaning of :id wrong!
Simone Heckmann (Nov 03 2016 at 10:49):
(deleted)
James Agnew (Nov 03 2016 at 22:18):
@Grahame Grieve I'm not sure I get your question on the OAuth part. I'd assume the OAuth authentication process is external to the FHIR server (as it always is of course) so by the time the client wants to open a websocket connection it presents the bearer token in its initial request before the connection gets upgraded to a websocket
James Agnew (Nov 03 2016 at 22:20):
Also how do we imply that you can only subscribe to a single ID? You can subscribe to any search result, so by definition it's lots of IDs no?
I do agree that the protocol needs work (and/or further fleshing out) though. This would be a nice time to do that.
Grahame Grieve (Nov 03 2016 at 22:26):
well, if you connect to a web socket end point, and it doesn't like your authentication, does it redirect the client to an OAuth end point instead of doing the websocket upgrade?
Grahame Grieve (Nov 03 2016 at 22:26):
do web socket clients handle that? what's the expectation with this elsewhere
Grahame Grieve (Nov 03 2016 at 22:27):
as for binding - once you have a wb socket, then you (the client) send bind :[id]
Grahame Grieve (Nov 03 2016 at 22:27):
and then you get messages for that subscription, by it's logical id
Grahame Grieve (Nov 03 2016 at 22:28):
that is, for the one logical id
Grahame Grieve (Nov 03 2016 at 22:37):
also, you assume that the client just... knows... where to get the bearer token that it needs from....
John Moehrke (Nov 04 2016 at 12:16):
At the FHIR specification for a subscription stream, you can only specify that authentication and authorization apply. For Connectathon you can define a specific policy to enforce. Subscriptions often do an access control check at both the subscription request, and prior to returning results. The first check is to confirm that the subscriber has proper rights to ask the subscription(question). This is often broad, meaning it doesn't do fine-grain rejections. The second (N) check(s) do the fine grain check (and re-verification that the requester is still authorized to subscribe). The second check(s) can choose to silently discard unauthorized data, or notify the subscriber (policy decision).
Grahame Grieve (Nov 04 2016 at 18:54):
and that answered the question how?
James Agnew (Nov 04 2016 at 22:34):
I definitely don't think we'd be doing any redirecting. Websockets are initiated by Javascript request so a simple 403 is probably all a client would be able to do anything useful with.
I guess a more fundamental question is why we get into the authorization stuff at all on the subscription page? I mean I would equally assume that searches are appropriately secured, but we don't mandate any particular authorization scheme there.
James Agnew (Nov 04 2016 at 22:37):
Re. the ID you're right. I'm now remembering that when I originally implemented the websocket protocol I read it wrong and assumed it was sending the IDs of the changed resources but that turned out to be incorrect and I had to fix it.
It probably makes sense to revisit the protocol as a whole, allowing for the server to send resource IDs or even bodies. I have trouble envisioning a use case where receiving the subscription ID would be useful for anything other than causing me to execute a follow-on search. Might as well just do the follow-on search proactively and send the results..
Grahame Grieve (Nov 04 2016 at 23:10):
the id of just sending the id of the subscription is that you could do that in the clear, or at least, with a lot less security
Grahame Grieve (Nov 04 2016 at 23:11):
I think from that point of view, if you're going to send the resource id, you might as well just send the resource
Grahame Grieve (Nov 04 2016 at 23:11):
I think it would be useful if you could bind more than one id
Grahame Grieve (Nov 04 2016 at 23:11):
e.g. bind :1 :2 :3
Grahame Grieve (Nov 04 2016 at 23:13):
as for security.. I agree we would say less e.g. remove the point "Client authenticates to server using a server-specified Web socket protocol (e.g. OAuth bearer token presentation)." and just add a note after the list to the effect that the web socket end-point must be appropriately secured
Abbie Watson (Dec 09 2016 at 02:37):
Ah... trying to implement a websocket pub/sub protocol and run FHIR resources over it? The Meteor community has had a pub/sub protocol called DDP (Data Distribution Protocol) running for the past 4 years, and have been running FHIR resources over it for the past year. This may be relevant. :)
https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
Grahame Grieve (Dec 09 2016 at 19:12):
@Josh Mandel - link to DDP is https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md
Abbie Watson (Dec 09 2016 at 19:14):
Also, just as an FYI.... the DDP protocol has open-source clients in a dozen major languages...
http://meteorpedia.com/read/DDP_Clients
Last updated: Apr 12 2022 at 19:14 UTC
