Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Torsten, Sorry for the delayed response, but since I was explicitly listed in the "To:" field I expect the response is still of interest. On Wed, Mar 04, 2020 at 05:19:13PM +0100, Torsten Lodderstedt wrote: > Hi all, > > based on the recent feedback, Vladimir and I propose the following chang

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Taka, I like the idea. I suppose there are tonnes of use cases where some data needs to be embedded into a JWT claims set, which could benefit from having its own container and content type, instead of doing what tried at first. I suppose this could merit a spec of its own (?). For the JWT intr

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Regarding the name of the JSON property in the payload of the introspection response JWT. If we choose a more generic name (e.g. "content") than "token_data", the approach discussed here can be used as a generic way to wrap a JSON response in JWT. If we are ambitious, we can even add "content_type

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

> Am 04.03.2020 um 19:18 schrieb Filip Skokan : > >  > Sorry, i meant - is top level jti required as well? I don’t see any use case for it, but that might be due to lack of creativity :-) > > S pozdravem, > Filip Skokan > > >> On Wed, 4 Mar 2020 at 19:15, Filip Skokan wrote: >> Torsten, l

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Sorry, i meant - is top level jti required as well? S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 19:15, Filip Skokan wrote: > Torsten, let's make sure we call out the required top level JWT claims - > iss, iat, aud, what else? is top level iat required as well? > > S pozdravem, > *Filip S

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Torsten, let's make sure we call out the required top level JWT claims - iss, iat, aud, what else? is top level iat required as well? S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt wrote: > Hi all, > > based on the recent feedback, Vladimir and I propose the follo

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Gotcha, thanks. I’d prefer without it, I don’t think the meaning is any more “special” than another container field would be. I like this kind of encapsulation, though. And to be honest, I wish we’d done that structure with dynamic registration as well. A software statement runs into similar is

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

no particular reason, just indicating special meaning. I can live without it.. > Am 04.03.2020 um 17:29 schrieb Justin Richer : > > Why the leading underscore in the name? Why not just “token_data”? > > — Justin > >> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt >> wrote: >> >> Hi all,

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Why the leading underscore in the name? Why not just “token_data”? — Justin > On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt > wrote: > > Hi all, > > based on the recent feedback, Vladimir and I propose the following changes to > draft-ietf-oauth-jwt-introspection-response: > > - the t

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi all, based on the recent feedback, Vladimir and I propose the following changes to draft-ietf-oauth-jwt-introspection-response: - the token data are encapsulated in a container element “_token_data” - beyond this, the top-level container only contains meta data pertinent to the JWT represe

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

+1, this encapsulation is much cleaner. > On Mar 2, 2020, at 2:25 AM, Filip Skokan wrote: > > Perhaps we should consider leaving the root level JWT claims as-is per JWT > and push the introspection response unmodified as if it was regular json > response to a JWT claim called "introspection".

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

> On 2. Mar 2020, at 18:27, Takahiko Kawasaki wrote: > > From RFC 7662, Section 2.1 > To prevent token scanning attacks, the endpoint MUST also require some form > of authorization to access this endpoint, such as client authentication as > described in OAuth 2.0 [RFC6749] or a separate OAuth

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

>From RFC 7662, Section 2.1 *To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Taka, I see, the audience is multi value. In my impression both specs assume a single value audience. But I think we can handle this as follows: Since the caller of the introspection respect is a single RS, the AS first needs to map & check the resources associated with the underlying acce

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Torsten, For example, if an authorization request includes two "resource" request parameters like below, resource=https://host1.example.com/resource1 resource=https://host2.example.com/resource2 RFC 8707 expects that the value of "aud" in an introspection response look like the following. "a

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Filip, Hi Taka, iat: We might add a structure (e.g. "underlying_access_token") to be able to convey “iat" for both the underlying access token as well as the JWT-formatted introspection response to the RS. I’m not really convinced we need to add this additional complexity since, in my experi

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hi Taka, > On 1. Mar 2020, at 08:10, Takahiko Kawasaki wrote: > > Hello, > > I'm wondering if the following conflicts in "JWT Response for OAuth Token > Introspection" (draft 8) have already been pointed out. > > RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an > intro

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Perhaps we should consider leaving the root level JWT claims as-is per JWT and push the introspection response unmodified as if it was regular json response to a JWT claim called "introspection". Since regular introspection uses the same claim names as JWT this would get around all the conflicts.

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 didn't exist then, though. *Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05* https://mailarchive.ietf.org/arch/

[OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Hello, I'm wondering if the following conflicts in "JWT Response for OAuth Token Introspection" (draft 8 ) have already been pointed out. RFC 8707 (Resource Indicators for OAuth 2.0)