FHIR Chat · Ballot reconciliation · smart

Stream: smart

Topic: Ballot reconciliation

Josh Mandel (Sep 29 2018 at 21:15):

We're pretty close to having all ballot changes in place from the 2017 ballot. Please take a look at http://build.fhir.org/ig/HL7/smart-app-launch/ and share feedback here or in a GH issue if you experience broken stuff :-)

Josh Mandel (Sep 29 2018 at 21:16):

@Dan Gottlieb

Pascal Pfiffner (Sep 30 2018 at 00:28):

Awesome, thanks! Found a typo: the second to last link on the page (7.2 "Request a FHIR resource") uses a comma rather than a period before "html", leading to a 404.

Josh Mandel (Sep 30 2018 at 13:00):

Thanks -- that whole H3 section was supposed to be cut (the individual links are inline with the sections they belong to). So... fixed by deleting :-)

Dan Gottlieb (Sep 30 2018 at 13:04):

Pedantic point - the second bullet in 2 should make it clear that the state is in the token response rather than the access token (people keep trying to parse tokens that should be opaque :)

Josh Mandel (Sep 30 2018 at 13:55):

Thanks -- fixed.

Josh Mandel (Sep 30 2018 at 13:58):

I should point out that there are a few pages within the spec that deserve review:

• http://build.fhir.org/ig/HL7/smart-app-launch/conformance/index.html
• http://build.fhir.org/ig/HL7/smart-app-launch/conformance/fhir-conformance-artifacts/index.html
• http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context/index.html
• http://build.fhir.org/ig/HL7/smart-app-launch/downloads/index.html
• http://build.fhir.org/ig/HL7/smart-app-launch/worked_example_id_token/index.html

Mikael Rinnetmäki (Sep 30 2018 at 16:04):

http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context/index.html#user-level-scopes includes a note on "Manage all resources on behalf of the authorizing user" that seems to be copy-pasted from above and not applicable here: "Note that the permission is broader than our goal: with this scope, an app can add not only blood pressures, but other observations as well. Also see notes on wildcard scopes below."

Mikael Rinnetmäki (Sep 30 2018 at 16:14):

The 3rd paragraph of http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context/index.html#scopes-for-requesting-identity-data ends with =======, which seems odd.

Mikael Rinnetmäki (Sep 30 2018 at 16:24):

On http://build.fhir.org/ig/HL7/smart-app-launch/worked_example_id_token/index.html#Validating-and-using-an-ID-Token-(for-clients) the paragraph ends abruptly: "A client obtains the ID Token as the result of an authorization operation. To validate the token, the client fetches the servers's public key, and then decodes the token. After decoding the tok"

Josh Mandel (Sep 30 2018 at 17:29):

Thanks! I'll get on these.... Done.

Robert Scanlon (Sep 30 2018 at 18:14):

Another minor issue, looks like you might be missing a "[" to properly create a markdown link to "section 4.1.3 of RFC6749" here: http://build.fhir.org/ig/HL7/smart-app-launch/#step-3-app-exchanges-authorization-code-for-access-token

Robert Scanlon (Sep 30 2018 at 18:46):

A sentence in http://build.fhir.org/ig/HL7/smart-app-launch/conformance/fhir-conformance-artifacts/index.html is a bit off: "The following FHIR artifact for have been defined for declaring conformance to the SMART’s App Launch specifications."

Robert Scanlon (Sep 30 2018 at 18:55):

Looks like you are missing a backtick before 'launch', causing strange formatting here http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context/index.html#apps-that-launch-from-the-ehr

Josh Mandel (Sep 30 2018 at 18:56):

Thanks Robert -- fixed these.

Isaac Vetter (Oct 01 2018 at 15:57):

@Josh Mandel - let me know if this isn't appropriate feedback or isn't the best place to provide it:

Note that this Implementation Guide applies to both DSTU2 and STU3 versions of FHIR.

It'd be better for this IG to apply to all, or at least, future versions of FHIR. Are we limited by the /metadata resource name change here? At minimum, this IG also applies to R4.

Isaac Vetter (Oct 01 2018 at 16:01):

mispelling:

An app SHALL NOT excecute any inputs it receives as code.

Josh Mandel (Oct 01 2018 at 16:17):

Fixing the typo. For the version issue I'm planning to say:

This profile is intended to be used by developers of apps that need to access
FHIR resources by requesting access tokens from OAuth 2.0 compliant
authorization servers. It is compatible with FHIR DSTU2 and above, and includes
explicit definitions for extensions in DSTU2 and STU3.

... but the important thing is that the guide does include artifacts that are DSTU2 and STU3 specific.

Isaac Vetter (Oct 01 2018 at 16:24):

Use the confidential app profile if your app is able to protect a client_secret

App is a native app that uses additional technology (such as dynamic client registration and universal redirect_uris) to protect the client_secret

@Josh Mandel - how does the above text permit native/mobile apps that use PKCE without a client_secret? You link to a specific section of the OAuth2 for Native Apps spec (that disallows static client_secrets), but that spec also defines the use of PKCE, which isn't otherwise mentioned in SMART.

This seems like a problem.

Josh Mandel (Oct 01 2018 at 16:26):

Agreed that we don't go deep on native app protections and details; the "additional technology" piece was intended to cover this; we went through this in ballot reconciliation last year, and landed here.

Isaac Vetter (Oct 01 2018 at 16:29):

We landed on the idea that PKCE is a great way to protect mobile apps. My concern is that it sounds like SMART is strongly recommending/requiring that mobile confidentials apps can only be protected with dynreg+OS uris, which is neither accurate nor what was balloted (per my extremely fallible memory).

Josh Mandel (Oct 01 2018 at 16:31):

This particular language was provided as a PR and reviewed at ballot time if memory serves. In any case, let's discuss what we might rather see here.

Josh Mandel (Oct 01 2018 at 16:32):

@Pascal Pfiffner

Pascal Pfiffner (Oct 01 2018 at 16:35):

I didn't think the language read as to _only_ allow dynreg since it says such as.

Pascal Pfiffner (Oct 01 2018 at 16:38):

NB: I think the first comma is one too many in the last bullet point in section 4: "Register one or more, fixed, fully-specified redirect_uri...".

Pascal Pfiffner (Oct 01 2018 at 16:41):

@Isaac Vetter is the contested text only the second bullet for confidential clients? Do you think this can be cleared up by adding "and other" (or similar) to the parenthesized text? Can you extend on the PKCE remark, where would that come in?

Isaac Vetter (Oct 01 2018 at 17:40):

Hey Pascal!

is the contested text only the second bullet for confidential clients?

Yes, i think so.

Do you think this can be cleared up by adding "and other" (or similar) to the parenthesized text?

Yes!

Isaac Vetter (Oct 01 2018 at 17:40):

What do you guys think about:

(such as dynamic client registration and universal redirect_uris, PKCE, or other technologies)

Isaac Vetter (Oct 01 2018 at 17:40):

PKCE really is a first-class technology for this problem, I can understand a hesitancy to add another acronym referring a complex technology. (We do more generally reference RFC8252 in section 4).

Josh Mandel (Oct 01 2018 at 17:45):

The challenge with tweaking that parenthetical is that it applies to confidential clients, where PKCE wouldn't necessarily.

Josh Mandel (Oct 01 2018 at 17:46):

We might want to say something about public clients where PKCE is involved

Josh Mandel (Oct 01 2018 at 17:48):

Re: PKCE it really would require more detailed specifications in order to make this interoperable. A native app might have to use PKCE with some EHRs, but other EHRs might not support it, which means that a client would need to know which systems to connect to with and without... It's kind of a can of worms if we start down this road, which is why I would prefer to leave it to a subsequent version to nail down these details.

Josh Mandel (Oct 01 2018 at 18:11):

Thanks for pointing out that stray comma BTW -- fixed @Pascal Pfiffner .

Pascal Pfiffner (Oct 01 2018 at 20:31):

PKCE wouldn't quite fit since it doesn't help to protect the client secret (which is I believe what 3.0.1 is calling out how to do). However it's a good call-out. It's referenced in the already-linked "OAuth 2.0 for Native Apps" document (https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-6), should we add an explicit link to Section 6 in addition to the link to Section 8.5?

Pascal Pfiffner (Oct 01 2018 at 20:31):

So I'd feel good with the sentence Isaac proposed minus PKCE:

Pascal Pfiffner (Oct 01 2018 at 20:32):

(such as dynamic client registration and universal redirect_uris or other strategies)

Pascal Pfiffner (Oct 01 2018 at 20:32):

(Ok, I also replaced technologies with strategies – I'm ok with either, I don't get to make this call since I'm not a native speaker :P )

Isaac Vetter (Oct 01 2018 at 20:33):

me too! (Sorry, Josh, I had to re-read the native apps rfc to remember how this stuff is supposed to work.)

Josh Mandel (Oct 01 2018 at 20:56):

should we add an explicit link to Section 6 in addition to the link to Section 8.5?

But PKCE isn't a strategy for protecting a secret; it's a strategy for making it less dangerous to lack a secret.

Josh Mandel (Oct 01 2018 at 20:57):

(Also, "such as" already implies an open list; I'd rather not add "or other strategies" unless folks feel strongly that it helps.)

Pascal Pfiffner (Oct 02 2018 at 22:17):

Ah yeah that's right, the header to these 3 bullet points says so much, I missed that.

Josh Mandel (Oct 04 2018 at 17:01):

Will work on publication request in the next FHIR-I quarter, FYI @Isaac Vetter

Josh Mandel (Aug 02 2021 at 20:00):

Call on now for SMART App Launch ballot reconciliation: https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09

Josh Mandel (Aug 09 2021 at 18:41):

At 4p ET (i.e., 80min from now) we'll continue with SMART on FHIR ballot reconciliation: https://hl7-org.zoom.us/j/8583747934?pwd=VnZiWFZsNm1TSk5QWmZlbVJyQVZGdz09

(The FHIR-I call at that zoom link starts at 3p ET with general FHIR-I topics and backlog -- the more the merrier.)

Josh Mandel (Aug 30 2021 at 18:52):

We've formally finished ballot reconciliation, but have one topic from @Bas van den Heuvel that we still want to take on, as a follow-up to FHIR-32210. Bas, are you prepared to discuss today / are you game for using the 2nd half of our FHIR-I call to do so?

Bas van den Heuvel (Aug 30 2021 at 18:58):

yes

Last updated: Apr 12 2022 at 19:14 UTC