Clarify relationship between Transmitter and AS #245
Conversation
… authorization server
|
@apoorvadeshpande-okta and @jischr to chat about combining PRs |
|
@FragLegs or @iamseanodentity can you take another look? |
| - All the SSF stream configuration management API operations MUST accept `ssf.manage` scope | ||
| - All the SSF stream configuration Read API operations MUST accept `ssf.read` scope | ||
| - Authorization server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc. | ||
| - Authorization Server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc. | ||
| - Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll` |
There was a problem hiding this comment.
| - Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll` | |
| - Transmitter managed poll endpoint SHOULD support the postfix scopes in the same nomenclature as `ssf.manage.poll` |
There was a problem hiding this comment.
To align with the changes from #208
There was a problem hiding this comment.
Why do you think this is a "SHOULD" versus a "MAY"? The reason we shouldn't have a SHOULD in this spec, is because we won't be able to determine if something is interoperable or not based on a "SHOULD". If it's a "MAY", it's just informational, and if it is a "MUST", then it can be tested for interoperability.
There was a problem hiding this comment.
Whatever gets decided, we should make sure #208 is fixed the same way as this
| * MAY distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [RFC8414]{{RFC8414}} | ||
| * MUST support at least one of the following to obtain a short-lived access token. For example, a short lived access token could be defined as one in which the value of the `exp` claim is not longer than 60 mins after `nbf` claim. Please refer to Access token lifetimes in the security considerations of {{FAPI}} for additional considerations. | ||
|
|
||
| An OAuth {{RFC6749}} Authorization Server issues access tokens. In the context of this profile, the Authorization Server that issues access tokens can be a separate entity than the SSF Transmitter. |
There was a problem hiding this comment.
An OAuth {{RFC6749}} Authorization Server that issues access tokens. (the word "that" is missing there)
There was a problem hiding this comment.
this is an informational line describing what an OAuth AS is. i don't think that makes sense gramatically.
We could rephrase it to align with your thoughts here
| - All the SSF stream configuration management API operations MUST accept `ssf.manage` scope | ||
| - All the SSF stream configuration Read API operations MUST accept `ssf.read` scope | ||
| - Authorization server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc. | ||
| - Authorization Server MAY postfix scope names with more granular operations eg. `ssf.manage.create`, `ssf.manage.update` etc. | ||
| - Transmitter managed poll endpoint MAY support the postfix scopes in the same nomenclature as `ssf.manage.poll` |
There was a problem hiding this comment.
Why do you think this is a "SHOULD" versus a "MAY"? The reason we shouldn't have a SHOULD in this spec, is because we won't be able to determine if something is interoperable or not based on a "SHOULD". If it's a "MAY", it's just informational, and if it is a "MUST", then it can be tested for interoperability.
tulshi
added
the
v1Final
|
We are not considering making the "CAEP Interoperability profile" a final spec in this round, so I will drop the "v1Final" label on this issue. |
tulshi
added
vFuture
and removed
v1Final
Fixes #203
I took a stab at this one as best as I could understand the issue and profile. Happy to rework the wording if it isn't quite right.