Stream: fhircast-github
Topic: fhircast-docs / Issue #237 May 2019 Ballot Comment:
Github Notifications (FHIRcast) (Apr 30 2019 at 19:54):
hl7-fhircast-bot opened Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer 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:54):
hl7-fhircast-bot labeled Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer 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:54):
hl7-fhircast-bot labeled Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer 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:54):
hl7-fhircast-bot labeled Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer 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:54):
hl7-fhircast-bot edited Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer token
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 01:53):
NiklasSvenzen labeled Issue #237
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer token
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 05 2019 at 01:56):
NiklasSvenzen commented on Issue #237
Propose that the lease should be less than och equal to oath access token expiration.
Github Notifications (FHIRcast) (May 23 2019 at 13:47):
wmaethner labeled Issue #237:
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer token
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 23 2019 at 13:47):
wmaethner commented on Issue #237:
Proposed resolution:
Persuasive with Mod
- If using oauth for authorization the Hub SHALL limit the subscription lease seconds to be less than or equal to the oauth access token expiration timestamp.
Github Notifications (FHIRcast) (Jun 18 2019 at 15:24):
isaacvetter commented on Issue #237:
## :telephone_receiver: II Working Group Vote (6-18-2019)
Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences
@JohnMoehrke moved the following disposition, seconded by @wmaethner
Disposition: Persuasive with Mod
Disposition Comment: If using oauth for authorization the Hub SHALL limit the subscription lease seconds to be less than or equal to the oauth access token expiration timestamp.
Additionally, we will update our Security Considerations page to call this out, including guidance for token expiration, revocation and other scenarios.:+1: For: 12
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Jun 18 2019 at 15:53):
wmaethner labeled Issue #237:
## May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer token
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 04 2019 at 20:25):
isaacvetter labeled Issue #237:
May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer token
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 10 2019 at 13:55):
isaacvetter closed Issue #237:
May 2019 Ballot Comment:
Submitted by @euvitudo
Chapter/section: Overview
Url: https://fhircast.hl7.org/specification/May2019Ballot/#overview
Type: NEG :exclamation:
In Person requested: Yes :bust_in_silhouette:Summary:
Comment: Initially I thought the spec didn't indicate what to do when the access token expires. However, I found information about renewal in a description field in a table. This should be in a dedicated section in the specification rather than buried in a table. Additionally, it would be helpful to know the corner cases that need to be handled by the client, e.g., after the access token expires, are messages to be queued up until the client renews the access token and if so, how long will messages be queued and will the be out of context by the time the client receives them? What is the life-cycle of a subscription and will the subscriptions be long-lived? (There are several other implications and/or corner cases that could be explored here.)
Existing wording: In all cases the app authenticates to the Hub with an OAuth 2.0 bearer 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
