Sorry your first email didn’t mention introspection. I answered assuming a JWT.
A JWE can have the issuer in the envelope, so the recipient just needs to
base64url decode the envelope to see who it issuer was and from that determine
where to introspect it.
However if you are introspecting the token why bother making it a JWE, just
send a regular JWS with a reference claim in the body that can be looked up by
the AS during introspection.
If you are trying to do stateless introspection then just send a JWE access
token containing the required claims and forget the introspection.
John B.
> On Mar 14, 2016, at 1:16 PM, Mike Schwartz <m...@gluu.org> wrote:
>
> This was the original requirement:
>
> " multiple authorization servers that can issue access tokens for one
> resource server, when the resource server receives an access token from a
> client application, as the first step, the resource server has to determine
> which authorization server to use for access token introspection."
>
> Not sure we're all on the same page after numerous responses...
>
> So the fact that the token is an encrypted JWT is great... the question is:
> who issued it? That's why I was thinking of a url encoded JWT with the issuer
> + the encrypted token, such as {"iss": "https://as.example.com";, "token":
> "(encrypted JTW)"}
>
> - Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
