We are trying to close the loop on the aud claim. Verbally, it was described as required, but in the documentation it seems to be a suggestion. The auth servers had been implemented without aud as a requirement and was in alignment with this spec as currently written.
Here are the required claims in an access_token, per API:
The following fields shall be included in the JWT claim for access tokens issued by this authority:
* `iss`, with the URL at which the token generation request was received.
* `exp`, with a time no further than 1 hour in the future.
* `sub`, with unique ID of the client requesting the access token.
* `scope`, with an array of strings indicating the scopes granted.
* `jti`, according to RFC 7519.
If DSS is rejecting requests due to missing aud claim, there is a problem with the documentation-implementation agreement. I believe most stakeholders would keep the documentation as-is and ensure that DSS isn't rejecting due to missing aud, at least for the near term.
Unless I'm missing something, which is entirely possible, hence the ticket.
We are trying to close the loop on the
aud
claim. Verbally, it was described as required, but in the documentation it seems to be a suggestion. The auth servers had been implemented withoutaud
as a requirement and was in alignment with this spec as currently written.See reference for
aud
as a suggested claim:https://github.com/astm-utm/Protocol/blob/d7e55fff0b4c55203c20e9408643f20d1cd6435a/utm.yaml#L73
Here are the required claims in an access_token, per API:
If DSS is rejecting requests due to missing
aud
claim, there is a problem with the documentation-implementation agreement. I believe most stakeholders would keep the documentation as-is and ensure that DSS isn't rejecting due to missingaud
, at least for the near term.Unless I'm missing something, which is entirely possible, hence the ticket.