Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Yep, I agree. But that's just me agreeing with it. Unless the spec clearly says it everybody will throw different ideas and use cases. That's why I want the spec to clarify this. On Wed, Mar 4, 2020, 1:42 PM Justin Richer, wrote: > Why would the client need to know the refresh token’s expiry? Ca

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Why would the client need to know the refresh token’s expiry? Can’t they just use the refresh token and see? Either way it’s a single round trip to the AS and the client gets the same answer with the same recovery code path. — Justin > On Mar 4, 2020, at 2:01 PM, Bill Jung > wrote: > > The

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

I can see the confusion in interpreting these requirements together. However, this is giving a specific semantics to omitted fields such that they’re treated as included in a specific way — with a null value. The intent of “include everything” is that you don’t leave out values and expect them t

Re: [OAUTH-WG] OAuth and OpenID Connect enterprise profiles

Daniel, Thank you for your feedback! We’re definitely interested in aligning with FAPI and with the proposed OAuth 2.1, as that could greatly simplify what we need to specify in our enterprise profiles if we can point to one or both as a baseline, and help provide a common set of requirements

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-03-09

Here's a link to DPoP in the fancy new HTML format https://www.ietf.org/id/draft-fett-oauth-dpop-04.html On Thu, Feb 27, 2020 at 12:40 PM Daniel Fett wrote: > What about DPoP? > > -Daniel > > Am 27.02.20 um 18:51 schrieb IESG Secretary: > > The Web Authorization Protocol (oauth) Working Group wi

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

The question started when some RPs (client apps) asked that AS allow introspection endpoint to RPs so that RPs can check their refresh token's expiry. If AS allows this, which the spec is not clear about, then AS needs to know if the request is coming from RP or RS so that AS can allow the Access T

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Yes, actually the term "protected resource" is awkward. It is the resource server's jog to introspect tokens to protect those protected resources. [image: Ping Identity] Bill Jung Manager, Response Engineering bj...@pingidentity.com w: +

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] RFC 7592 - Client Update Request omitted fields

I guess what i meant to call out is that while you and the spec says how omitted fields should be handled, but in the same section earlier it states that all fields must be included. S pozdravem, *Filip Skokan* On Wed, 4 Mar 2020 at 17:35, Justin Richer wrote: > I’m not sure what you’re asking

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] OAuth 2.1: dropping password grant

Again — isn’t this just the client credentials grant but with extra steps? — Justin > On Mar 1, 2020, at 11:33 AM, Phillip Hunt wrote: > > Why not just require service accounts to use mutually acceptable http method > of authentication? Eg instead id/password, service acnt client could use

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

Got it, thanks! Best, Filip On Wed, 4 Mar 2020 at 17:35, Justin Richer wrote: > I’m not sure what you’re asking — the text is not left over from anything > and is intentionally included. That text is saying that if I leave out the > field then the server treats it just like as if I had sent in

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

I’m not sure what you’re asking — the text is not left over from anything and is intentionally included. That text is saying that if I leave out the field then the server treats it just like as if I had sent in a null value. So the following are equivalent: { “client_name”: “foo”, “tos_uri”

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] RFC 7592 - Client Update Request omitted fields

So the following Omitted fields MUST be treated as null or empty values by the server, > indicating the client's request to delete them from the client's > registration. Does not mean the server needs to accept requests where fields are omitted? Is that a left over from previous drafts then? S

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] RFC 7592 - Client Update Request omitted fields

Your interpretation was our intent with that. It’s a full replace of the object. We had debating having PATCH style semantics, but ultimately decided that that was too complex for the most common update actions that a client would have. — Justin > On Mar 3, 2020, at 8:42 AM, Filip Skokan wro

Re: [OAUTH-WG] OAuth Topics for Vancouver

Thanks Rifaat, I'd like to request some time on the agenda to discuss general PoP ideas, issues, direction, etc.. On Mon, Jan 20, 2020 at 8:33 AM Rifaat Shekh-Yusef wrote: > All, > > Please, let us know if you have any topics that you would like to present > and discuss in Vancouver. > > Regard