Hi Alexey,
FYI, the only place in the spec that case-insensitive comparisons exist are
comparisons done by the Designated Experts when considering IANA registrations.
If implementations had to do case-insensitive comparisons, then yes,
recommending toLowerCase() would absolutely make sense,
Hi Vladimir,
Yes, the settings that the AS uses to create that JWT are established
out-of-band. Being the issuer of the token in the first place, I'd like
to see it being authoritative in choosing a secure way of doing so.
Thinking of it, the suggestion to advertise those cryptographic
Hi Mark,
The Nginx module is superbly documented, well done!
I suppose there's a set JWS alg for the issued tokens, which is agreed
in advance?
Vladimir
On 28/02/18 12:49, Mark Dobrinic wrote:
> Having the introspect endpoint support a response Content-Type of
> `application/jwt` is exactly
Hi Mike,
I've suggested one extra clarification, but the rest of the changes made
the document better.
Thank you,
Alexey
On Wed, Feb 28, 2018, at 3:04 AM, Mike Jones wrote:
> I believe that the changes in
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-09 address the
> DISCUSS and
Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-discovery-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Having the introspect endpoint support a response Content-Type of
`application/jwt` is exactly what we're doing in Curity. We actually
gave it a cool name in the process, a Phantom Token ;)
Doing things this way has proven highly useful in usecases where
customers have high throughput
On 28/02/18 09:48, Torsten Lodderstedt wrote:
> Hi all,
>
> I have an use case where I would like to return signed JWTs from the
> authorization server’s introspection endpoint. In this case, I would like to
> give the resource server evidence about the fact the AS minted the access
> token and
