Stream: fhircast-github
Topic: fhircast-docs / Issue #178 May 2019 Ballot Comment: Tight...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot opened Issue #178
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #178
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #178
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot labeled Issue #178
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:53):
hl7-fhircast-bot edited Issue #178
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 03:20):
isaacvetter commented on Issue #178
NOTE on ANSI modal verbs: The usage of ANSI modal verbs consistently provides a vehicle for quickly discerning the conformance criteria.
HL7 adheres to ISO/IEC directive, Appendix G: ANSI modal verbs ("SHALL", "SHOULD", "MAY", "SHALL NOT", "SHOULD NOT", "MAY NOT") SHALL be capitalized. See FHIR conformance rules, section 2.1.0.1 "Conformance Language". http://hl7.org/implement/standards/fhir/conformance-rules.html
Github Notifications (FHIRcast) (May 06 2019 at 16:25):
isaacvetter commented on Issue #178
Tony,
The nuance here is that the OAuth2 RFCs and SMART as well, clearly places the responsibility and authority for determining the scopes that a client is authorized for, on the authorization server.
If FHIRcast stated that:
app SHALL request and SHALL be granted the fhircast OAuth2.0 scope
We run the risk of contradicting OAuth and the authorization server's ability to actually determine if authorizing the FHIRcast client is appropriate.
How about adding the phrase "if authorized, ", in this paragraph --
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and if authorized, SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
Isaac
Github Notifications (FHIRcast) (May 21 2019 at 13:14):
wmaethner labeled Issue #178:
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:26):
wmaethner commented on Issue #178:
## :landline: II Working Group Vote (6-18-2019)
Block vote@isaacvetter moved the following disposition, seconded by Ricardo Quintano Neira
Disposition: Persuasive
Disposition Comment: Will fix as described in the issue comments or by the commenter:+1: For: 10
:expressionless: Abstain: 2
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jun 18 2019 at 15:27):
wmaethner labeled Issue #178:
## May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 18 2019 at 15:39):
wmaethner edited a comment on Issue #178:
## :landline: II Working Group Vote (6-18-2019)
Block vote@isaacvetter moved the following disposition, seconded by Ricardo Quintano Neira
Disposition: Persuasive with mod
Disposition Comment: Will fix as described in the issue comments or by the commenter:+1: For: 10
:expressionless: Abstain: 2
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Sep 03 2019 at 21:58):
isaacvetter closed Issue #178:
May 2019 Ballot Comment: Tighter restriction on Conformance Criteria.
Submitted by Anthony Julian
Chapter/section: Session discovery
Url: https://fhircast.hl7.org/specification/May2019Ballot/index.html
Type: NEG :exclamation: Clarification
In Person requested: Yes :bust_in_silhouette:Summary: Tighter restriction on Conformance Criteria.
Comment: See note on ANSI Modal Verbs: The phrase "the app may" negates the SHALL in the beginning of the sentence. It is important to require (SHALL be granted) the Oauth2.0. Likewise it is important to mandate the app SHALL receiver the id_token.
Existing wording: The app MUST either be launched from the driving application following the SMART on FHIR EHR launch flow or the app may initiate the launch following the SMART on FHIR standalone launch. In either case, the app MUST request and be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server MUST supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectivly. Per SMART, when scopes of openid and fhirUser are granted, the app will additionally receive the current user's identity in an id_token.
Proposed wording: The app SHALL either be launched from the driving application following the SMART on FHIR EHR launch flow or initiate the launch following the SMART on FHIR standalone launch. In either case, the app SHALL request and SHALL be granted the fhircast OAuth2.0 scope. Accompanying this scope grant, the authorization server SHALL supply the cast-hub and hub.topic SMART launch parameters alongside the access token. These parameters identify the Hub's base url, and a unique, opaque identifier of the current user's session, respectively. Per SMART, when scopes of openid and fhirUser are granted, the app SHALL additionally receive the current user's identity in an id_token.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Last updated: Apr 12 2022 at 19:14 UTC
