Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ballot#63 Hans Buitendijk | http://www.hl7.org/fhir/smart-app-launch/index.html# support-for-public-and-confidential-apps Should this call out the ... #67

Closed
jmandel opened this issue Dec 21, 2017 · 0 comments

Comments

@jmandel
Copy link
Collaborator

jmandel commented Dec 21, 2017

Ballot Weight

NEG Enhancement

Where

:: http://www.hl7.org/fhir/smart-app-launch/index.html

What

Hans Buitendijk
Comment: http://www.hl7.org/fhir/smart-app-launch/index.html# support-for-public-and-confidential-apps Should this call out the offline_access scope? I believe we don't feel like confidential is worth it for other use cases? Similar call to clarification, but not as specific: smart-on-fhir/smart-on-fhir.github.io#149 Note: Josh has also added this issue, calling out other use cases where the app could be confidential. We may want to add comments there (it's not the same issue as above, but is related): smart-on-fhir/smart-on-fhir.github.io#146
Summary: Confidential App Recommentation

Josh's Triage Notes

Merge with theme: "offline_access"

I think the key motivation was to avoid confusion by not assigningn a "secret" to apps that don't/can't keep a secret. But more generally: having asecret does provide additional protection when it's available!

Disposition

See dispositoin for "Theme: offline_access"

Vote Details

Pro-Con-Abstain:
Date:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants