I’ve just realised that “crit” is for headers while the “scope” claim is in the payload, so a different approach would be needed in that case (or the scope would need to be duplicated into the headers).
Kind regards, Neil -- > On Wednesday, Mar 28, 2018 at 4:41 pm, Neil Madden <neil.mad...@forgerock.com > (mailto:neil.mad...@forgerock.com)> wrote: > I like this draft, but I want to clarify if it is intended that the response > JWT could be interpreted as an OpenID Connect ID Token? As the set of claims > can overlap (in particular, all required ID token claims are valid token > introspection response fields) and it seems highly likely that an AS will use > the same keys for signing both (and it definitely will when the client_secret > is used for signing), the signed response JWT could well be indistinguishable > from an ID token (for the resource owner) with some additional claims. > > If this is not the case, then maybe consider adding a “crit”: [“scope”] claim > to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) to > indicate that the scope claim must be understood. > > I can think of one potential use-case (I’ll let you decide the merits of it) > where it might actually be useful to explicitly allow the response to be an > ID Token. Consider an application (RS) that uses a traditional authorization > model: it authenticates a user, sets a cookie, and then based on who that > user is makes dynamic access control decisions to see what they are allowed > to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to modern > standards would be to replace the home-spun authentication system with OIDC, > but leave the rest in place. Now the system uses OIDC to authenticate the > user, sets the ID token as the cookie, and then still applies the same access > control decisions that it always has done. > > Now imagine that a new requirement comes in to support OAuth 2.0 access > tokens to allow delegation to third-party apps. A really simple way to > achieve that would be to put a filter/reverse proxy in front of the RS that > extracts access tokens coming in, performs signed JWT token introspection > against the AS to validate the token and then checks the the scopes are > appropriate for the request. It can then simply replace the access token in > the original request with the signed token introspection response (as ID > token) and forward it on to the original RS server. As the introspection > response is a valid ID token for the resource owner, the RS will then apply > all its normal access control checks to ensure that the resource owner > actually has the permissions that they have delegated to the client.. > > I think potentially that is quite an interesting application of this draft, > but I don’t think it was intended! I think probably a decision should be made > as to whether that kind of usage should be allowed and explicitly adjust the > draft to either allow or deny it. If it is allowed, then possibly there > should be a way for the caller to hint that they want the response to be a > valid ID token. > > Kind regards, > > Neil > > > On 18 Mar 2018, at 19:33, Torsten Lodderstedt <tors...@lodderstedt.net > > (mailto:tors...@lodderstedt.net)> wrote: > > Hi all, > > > > I just submitted a new draft that Vladimir Dzhuvinov and I have written. It > > proposes a JWT-based response type for Token Introspection. The objective > > is to provide resource servers with signed tokens in case they need > > cryptographic evidence that the AS created the token (e.g. for liability). > > > > I will present the new draft in the session on Wednesday. > > > > kind regards, > > Torsten. > > > > > Anfang der weitergeleiteten Nachricht: > > > Von: internet-dra...@ietf.org (mailto:internet-dra...@ietf.org) > > > Betreff: New Version Notification for > > > draft-lodderstedt-oauth-jwt-introspection-response-00.txt > > > Datum: 18. März 2018 um 20:19:37 MEZ > > > An: "Vladimir Dzhuvinov" <vladi...@connect2id.com > > > (mailto:vladi...@connect2id.com)>, "Torsten Lodderstedt" > > > <tors...@lodderstedt.net (mailto:tors...@lodderstedt.net)> > > > > > > > > > A new version of I-D, > > > draft-lodderstedt-oauth-jwt-introspection-response-00.txt > > > has been successfully submitted by Torsten Lodderstedt and posted to the > > > IETF repository. > > > > > > Name: draft-lodderstedt-oauth-jwt-introspection-response > > > Revision: 00 > > > Title: JWT Response for OAuth Token Introspection > > > Document date: 2018-03-15 > > > Group: Individual Submission > > > Pages: 5 > > > URL: > > > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ > > > Htmlized: > > > https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00 > > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response > > > > > > > > > Abstract: > > > This draft proposes an additional JSON Web Token (JWT) based response > > > for OAuth 2.0 Token Introspection. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at tools.ietf.org > > > (http://tools.ietf.org/). > > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org (mailto:OAuth@ietf.org) > > https://www.ietf.org/mailman/listinfo/oauth >
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
