Hi Justin, Am 09.01.2013 um 20:35 schrieb Justin Richer <jric...@mitre.org>:
> Thanks for the review, answers inline: >> why is there a need for both scope and audience? I would assume the scope of >> the authorization request is typically turned into an audience of an access >> token. > > You can have an audience of a single server that has multiple scopes, or a > single scope that's across multiple servers. Scope is an explicit construct > in OAuth2, and while it is sometimes used for audience restriction > purposes, they really are independent. Note that both of these are optional > in the response -- if the AS has no notion of audience restriction in its > stored token metadata, then it just doesn't return the "audience" field. You are making an interesting point here. To differentiate the resource server and the permissions of a particular at this server makes a lot of sense. BUT: the authorization request does not allow the client to specify both in separate parameters. Instead both must be folded into a single "scope" parameter. If I got your example correctly, the scope of the request would be scope=myserver:read whereas the results of the introspection would be scope=read audience=myserver It's probably the different semantics of scope that confused me. > >> >> Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead >> of inventing another set of JSON elements? > > What would be the utility in returning a JWT? The RS/client making the call > isn't going to take these results and present them elsewhere, so I don't want > to give the impression that it's a token. (This, incidentally, is one of the > main problems I have with the Ping introspection approach, which uses the > Token Endpoint and invents a "token type" as its return value.) Also, the > resource server would have to parse the JWT instead of raw JSON, the latter > of which is easier and far more common. Besides, I'd have to invent new > claims for things like "valid" and "scopes" and what not, so I'd be extending > JWT anyway. > > So while I think it's far preferable to use an actual JSON object, I'd be > fine with re-using JWT claim names in the response if people prefer that. I > tried to just use the expanded text since size constraints are not an issue > outside of a JWT, so "issued_at" instead of "iat". > > Finally, note that this is *not* the same as the old OIDC CheckId endpoint > which merely parsed and unwrapped the data inside the token itself. This > mechanism works just as well with an unstructured token as input since the AS > can store all of the token's metadata, like expiration, separately and use > the token's value as a lookup key. I probably didn't describe well what I meant. I would suggest to return a JWT claim set from the introspection endpoint. That way one could use the same claims (e.g. iat instead of issued_at) for structured and handle-based tokens. So the logic operating on the token data could be the same. regards, Torsten. > > -- Justin > >> Am 09.01.2013 um 20:10 schrieb Justin Richer <jric...@mitre.org>: >> >>> Updated the introspection draft with feedback from the UMA WG, who have >>> incorporated it into their latest revision of UMA. >>> >>> I would like this document to become a working group item. >>> >>> -- Justin >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-richer-oauth-introspection-01.txt >>> Date: Tue, 8 Jan 2013 14:48:47 -0800 >>> From: <internet-dra...@ietf.org> >>> To: <jric...@mitre.org> >>> >>> A new version of I-D, draft-richer-oauth-introspection-01.txt >>> has been successfully submitted by Justin Richer and posted to the >>> IETF repository. >>> >>> Filename: draft-richer-oauth-introspection >>> Revision: 01 >>> Title: OAuth Token Introspection >>> Creation date: 2013-01-08 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>> Htmlized: >>> http://tools.ietf.org/html/draft-richer-oauth-introspection-01 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01 >>> >>> Abstract: >>> This specification defines a method for a client or protected >>> resource to query an OAuth authorization server to determine meta- >>> information about an OAuth token. >>> >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
