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

2015-07-18 Thread Aaron Parecki
In section 2.2, https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 the "scope" description references section 3.3 of RFC6749, but the hyperlink contains just the fragment #section-3.3 which then points to the current page. The same problem exists with the "token_type" paramet

[OAUTH-WG] Token introspection for public clients?

2015-07-18 Thread Aaron Parecki
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

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

2015-07-18 Thread Mike Jones
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?)

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

2015-07-18 Thread Justin Richer
Thanks, those are artifacts in the rendered XML, I’ll look into fixing them. — Justin > On Jul 19, 2015, at 3:24 AM, Aaron Parecki wrote: > > In section 2.2, > https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.2 >

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

2015-07-18 Thread Justin Richer
Public clients can use the token-based auth mechanism, can’t they? If you don’t have some form of authentication on the introspection endpoint, you end up with a way for people to anonymously and programmatically fish for valid token values. — Justin > On Jul 19, 2015, at 6:30 AM, Aaron Pare