I +1 this,
but at the same time, I'm wondering what happened with the argument that
this should be solved by Token Exchange instead of Introspect?
Cheers!
Mark
On 20/07/18 17:39, Phil Hunt wrote:
> +1 adoption
>
> I have always been concerned about clients doing introspection. Use of
> jwt he
Mark
On 28/02/18 17:16, Vladimir Dzhuvinov wrote:
> 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 wrot
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 requirements
Hey OAuth group,
While I though I knew this, I was looking closely at the OAuth 2.0 spec
and read that valid values of the client_id are specified as:
VSCHAR = %x20-7E
client-id = *VSCHAR
This means that the client-id may also contain whitespace characters.
Do I get that right?
Thanks for your
Just some way I could look at this discussion:
One way to separate an AS and an RS is specified by UMA, so for UMA it
is required to have a standardized Token Introspection feature.
If there are no other uses for separating AS/RS, then UMA would be the
place for standardizing Token Introspection.
