Hi George, > Am 01.06.2018 um 17:41 schrieb George Fletcher <gffle...@aol.com>: > > What is the expectation if the RS requests a signed JWT response but the AS > doesn't support it? Should getting a signed response require both? (meaning > the Accept header and an AS config that that RP wants it)? That may be the > safest from a backward compatibility perspective.
we assume the RS is set up with the AS in advance, so the RS should know whether the AS supports signing. > > I have some concerns around relying on 'iss' and 'aud' to prevent abuse It’s iss + aud + all replay prevention means you can think of (including token binding). > and wonder if a JWT Header claim describing the context of the JWT might be > better. Any suggestions (cty)? I’m not sure abuse can be prevented that way since developers need to consider this header claim. best regards, Torsten. > > Thanks, > George > > On 5/28/18 12:58 PM, Torsten Lodderstedt wrote: >> Hi all, >> >> I just published a new revision of the JWT Introspection response draft. >> Based on the feedback in London, the draft entirely focuses on use cases >> where the RS requires stronger assurance that the respective AS issued the >> token, including cases where the AS assumes liability for the token’s >> content. >> >> We incorporated the following changes: >> • fixed typos in client meta data field names (thanks Petteri!) >> • added OAuth Server Metadata parameters to publish algorithms >> supported for signing and encrypting the introspection response >> • added registration of new parameters for OAuth Server Metadata and >> Client Registration >> • added explicit request for JWT introspection response >> • made iss and aud claims mandatory in introspection response (thanks >> Neil!) >> • Stylistic and clarifying edits, updates references >> >> Thanks to all reviewers! >> >> Vladimir and I are on the fence whether the Introspection Response format >> should be determined by the AS based on its policy and/or RS-related >> registration metadata or whether the RS should explicitly request a JWT >> response by including an Accept header „application/jwt“ in the respective >> request. >> >> What do you think? >> >> kind regards, >> Torsten. >> >>> Anfang der weitergeleiteten Nachricht: >>> >>> Von: internet-dra...@ietf.org >>> Betreff: New Version Notification for >>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt >>> Datum: 28. Mai 2018 um 18:48:02 MESZ >>> An: "Vladimir Dzhuvinov" <vladi...@connect2id.com>, "Torsten Lodderstedt" >>> <tors...@lodderstedt.net> >>> >>> >>> A new version of I-D, >>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to the >>> IETF repository. >>> >>> Name: draft-lodderstedt-oauth-jwt-introspection-response >>> Revision: 01 >>> Title: JWT Response for OAuth Token Introspection >>> Document date: 2018-05-28 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.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-01 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01 >>> >>> 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. >>> >>> The IETF Secretariat >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
