Stream: fhircast-github
Topic: fhircast-docs / Issue #242 May 2019 Ballot Comment:
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot opened Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot edited Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 01:35):
NiklasSvenzen labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 01:46):
NiklasSvenzen commented on Issue #242
We will propose for the hub.topic to not be a URL as it does not add any value and is an acceptable deviation from WebSub due to the difference in content of the subscription.
Github Notifications (FHIRcast) (May 08 2019 at 14:54):
wmaethner labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 08 2019 at 18:47):
wmaethner commented on Issue #242
## Montreal May 2019 Working Group Vote
Isaac Vetter moved the following disposition, seconded by Will Maethner
Disposition: Not related
Disposition Comment: We will propose for the hub.topic to not be a URL as it does not add any value and is an acceptable deviation from WebSub due to the difference in content of the subscription.:+1: For: 12
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (May 08 2019 at 18:47):
wmaethner labeled Issue #242
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Jun 05 2019 at 14:15):
wmaethner unlabeled Issue #242:
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 05 2019 at 02:46):
isaacvetter commented on Issue #242:
Is "Not Related" really the correct disposition, above? It seems unlikely.
As Phil emphasizes, the
hub.topicshould be unique, unguessable, and session-specific. We were previously re-using thehub.topicboth as an session identifier, and also as the url to which the "query for current context" should be requested. We removed the query for current context during the ballot.Note also, that the "Request for context changes" was also previously being made at the
hub.topic. I changed this to the basehub.urlto satisfy this issue. The "request for context changes" message does include thehub.topicin the body. I'm not certain that this is the correct decision.I _think_ that a guid would be a good choice for this field by implementers.
Github Notifications (FHIRcast) (Sep 05 2019 at 02:47):
isaacvetter labeled Issue #242:
May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 10 2019 at 18:22):
isaacvetter closed Issue #242:
May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: App launch scenarios and session discovery
Url: https://fhircast.hl7.org/launch-scenarios/
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: There is an inconsistency between the unguessable nature of the hub.topic as provided via the SMART-on-FHIR/OAuth 2.0 exchange and the fact the hub.topic is a URL. WIth hub.topic being a URL, it is inherently no longer unguessable, as any network traffic inspector can see the URL that is being requested. Would suggest reworking the hub.topic (and any other sensitive values) to be placed either in the payload or in the headers of the request/response.
Existing wording: Specifically, the hub.topic url must be unique, unguessable, and specific to the session.
_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
