Stream: fhir/infrastructure-wg
Topic: FHIR-I Thu Q3
Josh Mandel (Oct 04 2018 at 17:52):
SMART Ballot Publication Request: draft
Josh Mandel (Oct 04 2018 at 18:27):
Updated SMART spec with MUST -> SHALL, fixed a typo at: https://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context/index.html
(this commit is what changed).
Also see this PR for one way to call attention to OIDC "Mandatory to Implement" without adding our own "SHALL" language: https://github.com/HL7/smart-app-launch/pull/284/files?short_path=ce47c6e#diff-ce47c6efdc1a32047e3daf6df7b30c2a
Michael Donnelly (Oct 04 2018 at 18:28):
I think I remember now the discussion we had about this before.
Josh Mandel (Oct 04 2018 at 18:29):
discussion reflected in our SMART spec, or something we missed in incorporating changes?
Michael Donnelly (Oct 04 2018 at 18:29):
Are those things already mandatory in the OIDC spec? And SMART is just calling attention to what's already required by OIDC?
Josh Mandel (Oct 04 2018 at 18:29):
Correct.
Josh Mandel (Oct 04 2018 at 18:29):
technically "Mandatory to implement" is what OIDC says.
Michael Donnelly (Oct 04 2018 at 18:32):
So our options (including unpalatable or very challenging ones) are:
1. Don't use OIDC at all.
2. Use OIDC as is. If someone doesn't implement those mandatory features, they are not compliant with OIDC. And a SMART implementer who says they do OIDC and who doesn't do those things is technically not compliant with SMART either, since they're saying they do OIDC when they don't really.
3. SMART says "OIDC says this is mandatory, but we say you MAY do it." The SMART spec technically conflicts with the OIDC spec, since it says you can do OIDC without doing things OIDC requires.
4. We change the OIDC spec.
Isaac Vetter (Oct 04 2018 at 18:33):
5) or, in SMART, clarify some of the arguably ambiguous language from OIDC
Michael Donnelly (Oct 04 2018 at 18:34):
Are you saying that your interpretation of OIDC is different from Josh's?
Isaac Vetter (Oct 04 2018 at 18:35):
For example:
OPs MUST support the prompt parameter, as defined in Section 3.1.2, including the specified user interface behaviors such as none and login.
OIDC 15.1
Josh Mandel (Oct 04 2018 at 18:35):
For (3), I wouldn't call this a conflict -- we say you can do OIDC, and we point out what OIDC says (see my proposed very tiny tweak
Michael Donnelly (Oct 04 2018 at 18:37):
Hmmm.
Isaac Vetter (Oct 04 2018 at 18:37):
OIDC defines 4 possible values for prompt. Which of these is required? Just none and login?
Isaac Vetter (Oct 04 2018 at 18:38):
A big part of SMART's value is that it profiles OAuth, just the important parts, please. That's missing here.
Josh Mandel (Oct 04 2018 at 18:40):
(And re: "prompt," the OIDC spec describes 4 values, and the minimum behavior on my reading would allow a server to return an error for each.)
Josh Mandel (Oct 04 2018 at 18:40):
To be clear, OIDC and OAuth are different beasts: OIDC defines is a complete login protocol, whereas OAuth is a protocol.
Josh Mandel (Oct 04 2018 at 18:40):
In profiling, we only ever add constraints, extensions, etc -- we never take away requirements from a base spec.
Josh Mandel (Oct 04 2018 at 18:41):
I'm not disputing that over time, we'll learn more and can write nice guidance to help developers understand and implement OIDC better; the question is what should we do right now?
Isaac Vetter (Oct 04 2018 at 18:41):
the minimum behavior on my reading would allow a server to return an error for each.)
Josh, would it be reasonable to add a tiny tweak to better set app developer expectations that this is reasonable behavior? I don't see how that's a necessary conclustion from reading the referenced OIDC sections.
Michael Donnelly (Oct 04 2018 at 18:42):
For 3, I was thinking of something in the vein of
- you can do these parts of OIDC
- and say you do sso-openid-connect
- and not do these things OIDC says you have to
- and you'll be compliant with SMART even though you aren't compliant with OIDC.
Michael Donnelly (Oct 04 2018 at 18:42):
I'm not saying that's what we should do. I'm saying it's on the list of options (along with terrible ones like "don't do OIDC at all").
Josh Mandel (Oct 04 2018 at 18:45):
Sure, it's on a list of options -- but OIDC is a strong security protocol for sign-in that has seen wide review + implementation, and I'm not comfortable just hacking bits off.
Michael Donnelly (Oct 04 2018 at 18:45):
I hear you.
Isaac Vetter (Oct 04 2018 at 18:47):
Yeah, me too, really!
Instead of hacking things off, can we guide both EHR and app developers to better understand which features are required and which can be expected?
Josh Mandel (Oct 04 2018 at 18:51):
Tell me more about what this would look like? In other words, do you mean we should include "tutorial" type material in our spec to bring developers up to speed with OIDC?
Michael Donnelly (Oct 04 2018 at 18:58):
In addition to https://github.com/HL7/smart-app-launch/pull/284/files we could say something like
The EHR SHALL return an OIDC error for any mandatory OIDC features it does not support
Michael Donnelly (Oct 04 2018 at 18:59):
That's a little clunky
Michael Donnelly (Oct 04 2018 at 18:59):
But something along those lines.
Josh Mandel (Oct 04 2018 at 19:05):
I'm sure that's okay for prompt. For display, better to just ignore it, which seems like a valid way to "implement" it, per the OIDC spec (which says, "Note that the minimum level of support required for this parameter is simply that its use must not result in an error."). For Signing ID Tokens with RSA SHA-256 ... this is pretty fundamental!
Preferred locales: also "minimum level of support required for these parameters is simply to have their use not result in errors"
Michael Donnelly (Oct 04 2018 at 19:08):
Isaac, which are the ones that really matter to us?
Last updated: Apr 12 2022 at 19:14 UTC
