Re: [OAUTH-WG] Token introspection for public clients?

I totally agree with that - and that’s how we gonna implement it in identity server. We are planning to introduce something called a “scope secret” - it’s like a client secret but for resources. —  cheers Dominick Baier On 20 Jul 2015 at 07:01:48, Justin Richer (jric...@mit.edu) wrote: Becau

Re: [OAUTH-WG] Token introspection for public clients?

Are you trying to use token introspection as evidence of authentication of the user? Phil @independentid www.independentid.com phil.h...@oracle.com > On Jul 20, 2015, at 12:03 AM, William Denniss wrote: > > I see in earlier drafts that client authentication MUST was a SHOULD. > > Why not put

Re: [OAUTH-WG] Token introspection for public clients?

Because the target isn’t the client, it’s the protected resource. We’re re-using OAuth’s client credentialing mechanisms (optionally, you can use whatever you deem necessary), but it’s not a client that’s doing it. That’s why it was changed to a MUST — there may be public clients out there (whic

Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11

Thanks for the pointers everyone, that should now be fixed in the copy in GitHub. I’ll publish a new draft this week sometime, after confirming the clearance of the final IESG DISCUSS. — Justin > On Jul 19, 2015, at 4:50 PM, Brian Campbell > wrote: > > Barry explained the tools issue that c

Re: [OAUTH-WG] Token introspection for public clients?

In the case of a “public client” using a token, the authorization is the token that the resource server uses to call the introspection endpoint, along side the token that it is introspecting. This is exactly how the UMA protocol works: the resource server has a “Protection API Token” that it use

Re: [OAUTH-WG] Token introspection for public clients?

How are public clients supposed to authenticate if there is no secret? Isn't "fishing for valid tokens" just as much of an issue at the resource server? I don't see how having the introspection endpoint require client authentication actually solves the fishing problem since attackers could just fi

Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11

Barry explained the tools issue that causes this and how to work around it a while back on the JOSE list: http://www.ietf.org/mail-archive/web/jose/current/msg04571.html On Sun, Jul 19, 2015 at 2:09 PM, John Bradley wrote: > Remember tools is not using the XML to render the HTML directly, it is

Re: [OAUTH-WG] broken links in draft-ietf-oauth-introspection-11

Remember tools is not using the XML to render the HTML directly, it is marking up the text version. This bites me all the time as well. The text version needs to render to “Section 3.3 of RFC 6749” to get Rfcmarkup tool to render it correctly.

Re: [OAUTH-WG] Token introspection for public clients?

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 c