That is one of the place that using a POP mechanism may be useful. If the client has established a key with the AS that issued the original token say via PKCE then, then it may be possible to bind the token being exchanged to the party exchanging it even if the exchanger has no pre exchanged credentials with the token exchange endpoint.
In the ACDC proposal part of profiling the assertion exchange was to require that they be POP tokens using PKCE as the confirmation method. I would like to think that the ACDC use case is something that can be addressed by the final token exchange spec. In OAuth and Connect we have three entities that receive tokens. 1, User agents: code, token, id_token (any of them might be PoP using token binding) 2, Clients: code (pop via PKCE) Refresh tokens (pop via Token binding?), access tokens (pop via the OAuth POP spec) , id_tokens (token binding via browser) , jwt or other assertions (?) 3 Resource Server: Access tokens ( these might be bound to the Audience of the token for exchange) To the original question. The client might use dynamic client registration, or it might use PKCE. In the PKCE case if the AT a POP token and the client uses it’s POP key to prove it it’s identity then it should be able to introspect the token. Though from a spec point of view there are admittedly still some gaps in doing that at the moment. John B. > On Jul 19, 2015, at 7:00 AM, Mike Jones <michael.jo...@microsoft.com> wrote: > > As a note for the upcoming Token Exchange discussion in Prague, I’ll note > that this same question may apply there. Specifically, can the party > requesting the exchange be a public client? (And does it have to be an OAuth > client at all?) > > Cheers, > -- Mike > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Aaron Parecki > Sent: Sunday, July 19, 2015 6:31 AM > To: OAuth WG > Subject: [OAUTH-WG] Token introspection for public clients? > > The introspection draft states that the introspection endpoint MUST require > authentication of clients. It mentions either client authentication > (id+secret) or a separate bearer token. > > How are public clients expected to use the token introspection endpoint? I > didn't see a note in the document about that at all. > > ---- > Aaron Parecki > aaronparecki.com > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faaronparecki.com&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OLWwlvUWyXz2HZaGyASvAlZ9fEhJt6a7A3%2bdfdgUdUY%3d> > @aaronpk > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2faaronpk&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U7RXStYZ1HIL%2bTlM99%2fYW8W9RPw8bTgHgXcjuvyK0t0%3d> > > _______________________________________________ > 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
