Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-07.txt
Hi all, Based on some of the discussions from our virtual interim meeting and the OAuth Security Workshop, I published a (minor) update to the browser app BCP. https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 The primary changes are: * Revised the language around PKCE/Implicit to clarify that PKCE applies only when issuing access tokens * Clarified that ASs MUST NOT issue access tokens in the authorization response * Changed "MUST" to "SHOULD" for rotating refresh tokens * Editorial clarifications to the summary bullet point section I believe these changes reflect all the latest discussions we've had. There are still some outstanding items I am aware of that need adding to the document as well. Apologies for the delay in getting this out. I hope we can pick up the momentum on this document again! Aaron Parecki On Fri, Oct 2, 2020 at 4:36 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > > Title : OAuth 2.0 for Browser-Based Apps > Authors : Aaron Parecki > David Waite > Filename: draft-ietf-oauth-browser-based-apps-07.txt > Pages : 21 > Date: 2020-10-02 > > Abstract: >This specification details the security considerations and best >practices that must be taken into account when developing browser- >based applications that use OAuth 2.0. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-07 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > 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
[OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename: draft-ietf-oauth-browser-based-apps-07.txt Pages : 21 Date: 2020-10-02 Abstract: This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JWT access tokens and the revocation endpoint
Hi WG, https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 provides the flowing about JWT access tokens “resource servers can consume them directly for authorization or other purposes without any further round trips to introspection ( [RFC7662]) or userinfo [OpenID.Core]) endpoints.” which is completely understandable. I do understand that the objective of this document is to standardize the token which the AS shares with the RS as it was discussed in other email threads. Here is what I would like to get a better understanding of: 1. How should a response of the introspection endpoint look like if the RS makes an attempt to introspect a JWT access token? 2. How should a response of the OpenID Connect userinfo endpoint look like for a JWT access token? I assume that it’s expected to have no difference compared to a regular bearer token (given that a particular implementation of the AS provides these endpoints). Does it sound right? If so, what are we going to get if the RS or the client revokes a valid JWT access token using the revocation endpoint (RFC 7009)? Do you think there is a need to add more detailed information about these scenarios in the document? This way, we could refer back to these sections in the documentation in case any disputes around security-related topics come up. Thank you. Regards, Andrii ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09
Hi Torsten! Sorry for my tardy response. Yes, the proposed edits and explanations address my concerns. Roman > -Original Message- > From: Torsten Lodderstedt > Sent: Wednesday, August 26, 2020 8:26 AM > To: Roman Danyliw > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection- > response-09 > > Hi Roman, > > thanks for your review feedback. > > > On 21. Aug 2020, at 16:43, Roman Danyliw wrote: > > > > Hi! > > > > I conducted an another AD review of draft-ietf-oauth-jwt-introspection- > response-09. As background, -07 of this document went to IESG Review and > the document was brought back to the WG to address the DISCUSS points. > > > > Below is my feedback which can be addressed concurrently with IETF LC. > > > > ** Section 5. I want to clarify what are the permissible members of > token_introspection. The two relevant text snippets seem to be: > > > > (a) "token_introspection A JSON object containing the members of the > > token introspection response, as specified in the "OAuth > > Token Introspection Response" registry established by > > [RFC7662] as well as other members." > > > > (b) "Claims from the "JSON Web Token Claims" registry that are > > commonly used in [OpenID.Core] and can be applied to the > > resource owner MAY be included as members in the > > "token_introspection" claim." > > > > -- Per (a), Recommend citing the IANA sub-registry directly -- > https://www.iana.org/assignments/oauth-parameters/oauth- > parameters.xhtml#token-introspection-response (and not the "as specified in > the "OAuth Token Introspection Response" registry established by [RFC7662]") > > done > > > > > -- Per (a), "... as well as other members", what members is this > > referencing? > Is that (b)? Recommend being clear upfront on which exact registries are the > sources of valid members. > > I reworked the whole paragraph (hrefs for registries not shown). > > As specified in section 2.2. of [RFC7662], specific implementations MAY extend > the token introspection response with service-specific claims. In the context > of > this specification, such claims will be added as top-level members of the > token_introspection claim. Response names intended to be used across > domains MUST be registered in the OAuth Token Introspection Response > registry defined by [RFC7662]. In addition, claims from the JSON Web Token > Claims registry established by [RFC7519] MAY be included as members in the > token_introspection claim. They can serve to convey the privileges delegated > to > the client, to identify the resource owner or to provide a required contact > detail, such as an e-Mail address or phone number. When transmitting such > claims the AS acts as an identity provider in regard to the RS. The AS > determines based on its RS-specific policy what claims about the resource > owner to return in the token introspection response. > > Does this work for you? > > > > > -- Per (b), "... commonly used in [OpenId.Core]", what are those > > specifically? > Is that claims registered in > https://www.iana.org/assignments/jwt/jwt.xhtml#claims whose reference is > [OpenID Connect Core 1.0]? Recommend being unambiguous in which claims > are permitted by pointing the IANA registry. > > > > -- If I'm understanding right that the source comes either from oauth- > parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what > happens if it isn't one of those? > > Every implementation is also free to use their own specific claims. This is > defined in section 2.2. of RFC > > > > > ** Section 5. Per " The AS MUST ensure the release of any privacy-sensitive > data is legally based", recommend also including a forward reference to > Section > 9 > > done > > best regards, > Torsten. > > > > > Regards, > > Roman > > > > ___ > > 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
