From 38517568536ec8c7fa09b12d984fd95536991b67 Mon Sep 17 00:00:00 2001 From: dblevins Date: Tue, 15 May 2018 22:00:58 -0700 Subject: [PATCH] Move Future Directions --- spec/src/main/asciidoc/configuration.asciidoc | 29 ------------------- .../main/asciidoc/future-directions.asciidoc | 27 +++++++++++++++++ 2 files changed, 27 insertions(+), 29 deletions(-) diff --git a/spec/src/main/asciidoc/configuration.asciidoc b/spec/src/main/asciidoc/configuration.asciidoc index 6d25a7d6..e9f4de28 100644 --- a/spec/src/main/asciidoc/configuration.asciidoc +++ b/spec/src/main/asciidoc/configuration.asciidoc @@ -378,32 +378,3 @@ is allowed. NOTE: In most cases relying on the digital signature check via the Public Key alone is sufficient to establish trust. - -### Future Direction - -Not all considerations discussed during the specification process make it into the -specification. This section serves as an abridged version for the purposes of soliciting -feedback and interest. By convention we will leave items in the Future Direction for -at most two revisions. - -#### `classpath:` URL Scheme - -The option to have a built-in `classpath:` URL Scheme was discussed with the intended -benefit of providing some way to explicitly state a Public Key file is inside the archive -and to remove potential a similarly named file existed on disk. - -For the moment this was deemed an edge-case that could be solved with a custom URL Scheme -and consensus that this would add to the complexity of the specification. In practice, -this may be very useful so those who find themselves with this scenario are encouraged -to contact the MicroProfile discussion lists. - -#### Expiration tolerance - -Relaxing or potentially ignoring the expiration time of a JWT was discussed and deemed -an attractive option for future standardization. It was omitted in efforts to keep the -first revision of the configuration as simple as possible. - -Users who find themselves with this need are encouraged to both request support from their -respective implementation and to detail their use case the MicroProfile discussion lists, -so any future standardization work accounts for all scenarios. - diff --git a/spec/src/main/asciidoc/future-directions.asciidoc b/spec/src/main/asciidoc/future-directions.asciidoc index a769b0fa..70d36b3b 100644 --- a/spec/src/main/asciidoc/future-directions.asciidoc +++ b/spec/src/main/asciidoc/future-directions.asciidoc @@ -18,6 +18,11 @@ [[resource_access]] ## Future Directions +Not all considerations discussed during the specification process make it into the +specification. This section serves as an abridged version for the purposes of soliciting +feedback and interest. By convention we will leave items in the Future Direction for +at most two revisions. + ### "resource_access" claim In future versions of the API we would like to address service specific group claims. The "resource_access" @@ -50,3 +55,25 @@ The "aud" claim defined in RFC 7519 section 4.1.3 was considered for addition. Though a "aud" claim is not required, implementations that support it and applications that use it should do so as detailed in this section to ensure alignment for any future standardization. + +### `classpath:` URL Scheme + +The option to have a built-in `classpath:` URL Scheme was discussed with the intended +benefit of providing some way to explicitly state a Public Key file is inside the archive +and to remove potential a similarly named file existed on disk. + +For the moment this was deemed an edge-case that could be solved with a custom URL Scheme +and consensus that this would add to the complexity of the specification. In practice, +this may be very useful so those who find themselves with this scenario are encouraged +to contact the MicroProfile discussion lists. + +### Expiration tolerance + +Relaxing or potentially ignoring the expiration time of a JWT was discussed and deemed +an attractive option for future standardization. It was omitted in efforts to keep the +first revision of the configuration as simple as possible. + +Users who find themselves with this need are encouraged to both request support from their +respective implementation and to detail their use case the MicroProfile discussion lists, +so any future standardization work accounts for all scenarios. +