Stream: connectathon mgmt
Topic: Direct Track
Grahame Grieve (Dec 23 2017 at 21:53):
@Calvin Beebe - I'm reading the direct track. and looking at scenario #B1 "Client authentication backed by trusted certificates" - what about using Smart backend services (see the bulk data track) - it appears that it's the same probllem being solved... (cc: @Josh Mandel ). btw, can you ask Luis to join us here for track coordination
Josh Mandel (Dec 23 2017 at 21:57):
Thanks for the cc! Yeah, I'm guessing the Direct approach relies on mutual TLS?
Grahame Grieve (Dec 23 2017 at 21:58):
well, there's various options. The #A options are mutual TLS, but the #B1 option relies on JWT exchange and looks equivalent to Smart back-end services
Josh Mandel (Dec 23 2017 at 22:27):
Looks like B1 uses "UDAP OAuth profile".
Josh Mandel (Dec 23 2017 at 22:28):
I don't see a link but googling suggests
http://www.emrdirect.com/udap.php
Grahame Grieve (Dec 23 2017 at 22:31):
that will surely be it, in that emrdirect is Luis and he's a track lead. I'll have to read it
Josh Mandel (Dec 23 2017 at 22:32):
I think this specification is designed to handle (a superset of) the same use cases as the SMART Backend services spec (http://docs.smarthealthit.org/authorization/backend-services/)
Grahame Grieve (Dec 23 2017 at 22:32):
that's why I started this
Josh Mandel (Dec 23 2017 at 22:33):
The SMART spec assumes that each client will be registered with the server before making a request. The UDAP specification allows for a trust framework to have some role -- from what I can understand this doesn't obviate the need for registration although sometimes maybe you can skip it.
Grahame Grieve (Dec 23 2017 at 22:33):
useful?
Josh Mandel (Dec 23 2017 at 22:34):
Probably -- it's designed to cover the case for an external organization can assign Trust. And it is also designed to handle the case where there might be a user involved other user is not the one doing the authorizing.
Josh Mandel (Dec 23 2017 at 22:35):
They definitely overlap and there may be an opportunity to iron out differences for the overlapping functionality!
Grahame Grieve (Dec 23 2017 at 22:37):
maybe a breakout?
Josh Mandel (Dec 23 2017 at 22:38):
Good idea. I think one of the main points of difference is that the EAP specification assumes there will be certificates for every party where has the smart specification really only focuses on public and private keys. This will be a good discussion!
Josh Mandel (Dec 23 2017 at 22:45):
One thing I want to discuss is some confusion I have about whether subject (sub) claim is designed to communicate information about the client or the user. There seems to be two contradictory statements made.
Grahame Grieve (Jan 27 2018 at 12:58):
@Julie Maas (I don't see an account for Luis) - the reason I require authentication prior to registering a client is that for a back-end services client, I would only allow it to have what rights the user that registers the client has - but then I forgot to actually implement that yet. For this weekend (at least) I have revoked that requirement)
Julie Maas (Jan 27 2018 at 15:20):
@Calvin Beebe FYI
Julie Maas (Jan 27 2018 at 15:35):
@Grahame Grieve Thank you!
Calvin Beebe (Jan 27 2018 at 16:27):
table #39
Calvin Beebe (Sep 29 2018 at 13:28):
The Direct / Certificates Track is upstairs in the Pisces
Calvin Beebe (Sep 29 2018 at 15:10):
Post-it board showed up
Last updated: Apr 12 2022 at 19:14 UTC
