Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05
Hello Thorsten, Thank you for your response. I have a few more questions/comments as follow-up... You state that RFC7519 and RFC7662 "just" define different representations for token data. If the draft RFC would refer to RFC 7515 (JWS), I would agree. However, RFC7519 (JWT) explicitly adds semantics to some specific parameters (e.g. aud, jti and iat). RFC7662 has different semantics for the several of the same parameters. For instance the 'iat', is the moment of issuance of the JWT in RFC7519. In RFC7662 that is the "when this token was originally issued". This time will vary in use cases without immediate introspection of an access token. For the use case of the resource server relying on verifiable data, as described in the introduction of the draft RFC, the time of the introspection is critical. In particular when combined with revocation, the time of introspection and the 'active' status can differ between two subsequent calls for introspection. If the draft RFC just produces a JWT representation of the access token, including 'active' would not make sense as the JWT will expire without updating it to false. Leaving 'active' out would make it incompatible with RFC7662 introspection responses. Similar, not including a unique 'jti' per introspection response would make the resource server vulnerable to replay attacks. Or the resource server would mistakenly refer to non-unique tokens, making the responses unsuitable for accountability and audit purposes. As to why someone would want to distinguish a JWT access token from an introspection response: several use cases come to mind. First of all, even if one is using standalone interpretable JWT access tokens, one may want to combine that with revocation checking using introspection. The interpretation and meaning of the JWT and the introspection response than do differ and matter. Another use case would be a mixed ecosystem with resource servers relying on introspection while others do parse JWT access tokens. A single, uniform implementation for the AS would than mix both as well. A last use case could be exchanging access tokens with a subset of the full set of applicable parameters, to reduce the size of access tokens. Additional information can be exchanged via introspection, resulting in mixed JWT access tokens and introspection as well. Kind regards, Remco Schaar -Oorspronkelijk bericht- Van: Torsten Lodderstedt Verzonden: zaterdag 17 augustus 2019 14:00 Aan: Schaar, R.M. (Remco) - Logius CC: oauth@ietf.org Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05 Hi Remco, > On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius > wrote: > > Hello, [...] RFC 7519 and RFC 7662 “just” define different representations for token data. In RFC 7519 the data is carried in the token itself (which also means the format of the token is well-defined and know to the RS) whereas RFC 7662 defines a way to inspect tokens via an API provided by the AS. The latter is typically used in conjunction with opaque tokens, i.e. the RS does not have a clue how to parse and interpret the token. The token might just be a handle to a database entry at the AS in this case. This also means a JWT (RFC 7662) and the Introspection Response are conceptually the same from a RSs perspective. [...] > The ‘jti’ parameter however will always be ambiguous. As it is an identifier, > it should differ for the introspected token and the introspection response by > definition. Hence the semantics of ‘jti’ in a JWT introspection response is > unclear. The same can apply to the ‘iat’, ‘nbf’ and ‘exp’ claims in a JWT > introspection response. I don’t understand the difference you are making. All before mentioned claims are related to the (abstract) access token. You may think of the Introspection Response as _the_ JWT representation of the access token produced by the AS for the RS. > > Can someone clarify the semantics of claims in an introspection response JWT > that are defined in both RFC7662 and RFC7519? > > Furthermore, the introspection response should use the ‘iss’ and ‘aud’ claims > to avoid cross-JWT confusion (section 6.1). The ‘iss’ and ‘aud’ of an > introspected token will typically be the same as those of the introspection > response. Hence a JWT access token cannot be distinguished from an > introspection response using ‘iss’ and ‘aud’ as suggested in the draft.. > > Introspection refers to JWT best-current-practice. The draft BCP recommends > using explicit typing of JWTs, however the draft JWT response for > introspection does not apply this recommendation and uses the generic > ‘application/jwt’ instead... The BCP has other recommendations in section > 3.12, but these may be insufficient to distinguish a JWT access token from a > JWT introspection response. Good point. The reason why the BCP recommends explicit typing is to prevent replay in other contexts. In the end typing is a
[OAUTH-WG] [Technical Errata Reported] RFC8252 (5848)
The following errata report has been submitted for RFC8252, "OAuth 2.0 for Native Apps". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5848 -- Type: Technical Reported by: Bayard Bell Section: Appendix B.1 Original Text - Apps can initiate an authorization request in the browser, without the user leaving the app, through the "SFSafariViewController" class or its successor "SFAuthenticationSession", which implement the in- app browser tab pattern. Safari can be used to handle requests on old versions of iOS without in-app browser tab functionality. Corrected Text -- Apps can initiate an authorization request in the browser, without the user leaving the app, through the "ASWebAuthenticationSession" class or its successors "SFAuthenticationSession" and "SFSafariViewController", which implement the in-app browser tab pattern. The first of these allows calls to a handler registered for the AS URL, consistent with Section 7.2. The latter two classes, now deprecated, can use Safari to handle requests on old versions of iOS without in-app browser tab functionality. Notes - SFAuthenticationSession documentation reflects deprecated status: https://developer.apple.com/documentation/safariservices/sfauthenticationsession Here's the documentation for ASWebAuthenticationSession: https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8252 (draft-ietf-oauth-native-apps-12) -- Title : OAuth 2.0 for Native Apps Publication Date: October 2017 Author(s) : W. Denniss, J. Bradley Category: BEST CURRENT PRACTICE Source : Web Authorization Protocol Area: Security Stream : IETF Verifying Party : IESG ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848)
Process-wise I'm not sure if errata should be used to capture changing implementation details like this. We expected the implementation details that we documented in the appendix to change, and explicitly stated that assumption. "The implementation details herein are considered accurate at the time of publishing but will likely change over time.". If updating those implementation details were in scope, then the proposed text should needs to be revised before being accepted due to some inaccuracies (e.g. SFSafariViewController is not a successor to ASWebAuthenticationSession). Best, William On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System < rfc-edi...@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8252, > "OAuth 2.0 for Native Apps". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5848 > > -- > Type: Technical > Reported by: Bayard Bell > > Section: Appendix B.1 > > Original Text > - > Apps can initiate an authorization request in the browser, without > the user leaving the app, through the "SFSafariViewController" class > or its successor "SFAuthenticationSession", which implement the in- > app browser tab pattern. Safari can be used to handle requests on > old versions of iOS without in-app browser tab functionality. > > Corrected Text > -- > Apps can initiate an authorization request in the browser, without > the user leaving the app, through the "ASWebAuthenticationSession" > class or its successors "SFAuthenticationSession" and > "SFSafariViewController", which implement the in-app browser tab > pattern. The first of these allows calls to a handler registered > for the AS URL, consistent with Section 7.2. The latter two classes, > now deprecated, can use Safari to handle requests on old versions of > iOS without in-app browser tab functionality. > > Notes > - > SFAuthenticationSession documentation reflects deprecated status: > > > https://developer.apple.com/documentation/safariservices/sfauthenticationsession > > Here's the documentation for ASWebAuthenticationSession: > > > https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8252 (draft-ietf-oauth-native-apps-12) > -- > Title : OAuth 2.0 for Native Apps > Publication Date: October 2017 > Author(s) : W. Denniss, J. Bradley > Category: BEST CURRENT PRACTICE > Source : Web Authorization Protocol > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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
