Stream: Security and Privacy
Topic: OAuth App Registration
John Moehrke (Apr 03 2018 at 14:27):
What should the FHIR specification say about App registration? It is a critical component of trust. Is there anything special for Healthcare, or is this just healthcare application of general-purpose app registration?
Grahame Grieve (Apr 03 2018 at 18:14):
I think that it makes sense to profile app registration as part of Smart - for the same reasons, and to map between smart choices and app registration choices unequivocally
John Moehrke (Apr 03 2018 at 19:19):
does it need to be tied to SMART?
Grahame Grieve (Apr 03 2018 at 19:20):
I don't think that app registration does, but smart app registration needs to be matched to smart apps
John Moehrke (Apr 18 2018 at 15:11):
Note there is a Track at the upcoming FHIR connectathon in Cologne that has one proposal for App Registration. See http://wiki.hl7.org/index.php?title=201805_Direct/Certificates_Track Please comment here to help drive toward one or more solutions.
Julie Maas (Feb 06 2019 at 01:20):
John et al., a few of us are beginning to put a document together to address this question and would appreciate feedback and for others to become involved; please see draft document here: https://docs.google.com/document/d/1yMNGDtB2X_6Maj8MAeVVv3ZI4z0X6LZAo5SisPuT_6k
John Moehrke (Feb 06 2019 at 13:48):
@Josh Mandel @Grahame Grieve @Ewout Kramer and others...
Josh Mandel (Feb 06 2019 at 17:17):
Thanks much for the call-out here! I love that this is coming together. I've sprinkled some questions and comments within the doc (mostly centered around the question of whether cert chaining is a strict requirement).
Luis Maas (Feb 06 2019 at 19:30):
@Josh Mandel If you are asking whether certs must be issued by a separate CA, then no, that is not a strict requirement. For example, a self-signed certificate could be used in UDAP flows if this is allowed by a trust community or by local policy and that certificate is trusted by the relying party. A trust bundle containing both trusted issuers and self-signed end-entity certificates is also possible.
Josh Mandel (Feb 07 2019 at 05:49):
Thanks! (I added more detailed comments in the doc about whether this is a special case or a common case).
Ryan Howells (Apr 20 2020 at 21:08):
Julie Maas said:
John et al., a few of us are beginning to put a document together to address this question and would appreciate feedback and for others to become involved; please see draft document here: https://docs.google.com/document/d/1yMNGDtB2X_6Maj8MAeVVv3ZI4z0X6LZAo5SisPuT_6k
Hey @Julie Maas : Whatever happened to this document? Should folks be looking here or somewhere else for the context around UDAP, POET, etc. and other general app registration guidance?
Tom Jones (Apr 20 2020 at 22:36):
It seems like the doc is dead. I made a comment, but not clear if it is germain to the purpose of the doc. Am i correct in assuming that the scope of this doc is limited to apps loaded on the user's device that rely on an external source of an identifier? (ie does not use a self-issued identifier). -- It really could use a scope staatement.
Julie Maas (Apr 20 2020 at 23:45):
Thanks @Tom Jones. I would be happy to clarify this next time I have a chance to make additional comments in the document. Trusted registration is intended only for clients capable of securing a private key. @Ryan Howells udap.org is a good reference for context as are some blog posts I've written. If you'll be more specific about the audience I can make some suggestions.
Tom Jones (Apr 21 2020 at 19:10):
well - i can list the types of user platforms that i know - perhaps at the least the doc could be clear where its audience might be: for example, every person in the US that needs health care and has at least an 8th grade education and ability to operate a computing device, or whatever metric you might chose. -- But to be clear - the context needs to be IN THE DOC.
Tom Jones (Apr 21 2020 at 19:35):
===Expected Types of Access Methods===
For users with some computer literacy:
Browser on a personal or public device
User portable device with browser and local storage for continued connectivity.
User agent running the cloud that can be accessed with any browser
User agent in a native app on a user owned device using traditional sources of an identifier
User agent in a native app on a portable user owned device with a self-issued identifier
Last updated: Apr 12 2022 at 19:14 UTC
