diff options
Diffstat (limited to 'doc/rfc/rfc9470.txt')
| -rw-r--r-- | doc/rfc/rfc9470.txt | 707 |
1 files changed, 707 insertions, 0 deletions
diff --git a/doc/rfc/rfc9470.txt b/doc/rfc/rfc9470.txt new file mode 100644 index 0000000..b58214b --- /dev/null +++ b/doc/rfc/rfc9470.txt @@ -0,0 +1,707 @@ + + + + +Internet Engineering Task Force (IETF) V. Bertocci +Request for Comments: 9470 Auth0/Okta +Category: Standards Track B. Campbell +ISSN: 2070-1721 Ping Identity + September 2023 + + + OAuth 2.0 Step Up Authentication Challenge Protocol + +Abstract + + It is not uncommon for resource servers to require different + authentication strengths or recentness according to the + characteristics of a request. This document introduces a mechanism + that resource servers can use to signal to a client that the + authentication event associated with the access token of the current + request does not meet its authentication requirements and, further, + how to meet them. This document also codifies a mechanism for a + client to request that an authorization server achieve a specific + authentication strength or recentness when processing an + authorization request. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9470. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Conventions and Terminology + 2. Protocol Overview + 3. Authentication Requirements Challenge + 4. Authorization Request + 5. Authorization Response + 6. Authentication Information Conveyed via Access Token + 6.1. JWT Access Tokens + 6.2. OAuth 2.0 Token Introspection + 7. Authorization Server Metadata + 8. Deployment Considerations + 9. Security Considerations + 10. IANA Considerations + 10.1. OAuth Extensions Error Registration + 10.2. OAuth Token Introspection Response Registration + 11. References + 11.1. Normative References + 11.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + In simple API authorization scenarios, an authorization server will + determine what authentication technique to use to handle a given + request on the basis of aspects such as the scopes requested, the + resource, the identity of the client, and other characteristics known + at provisioning time. Although that approach is viable in many + situations, it falls short in several important circumstances. + Consider, for instance, an eCommerce API requiring different + authentication strengths depending on whether the item being + purchased exceeds a certain threshold, dynamically estimated by the + API itself using a logic that is opaque to the authorization server. + An API might also determine that a more recent user authentication is + required based on its own risk evaluation of the API request. + + This document extends the collection of error codes defined by + [RFC6750] with a new value, insufficient_user_authentication, which + can be used by resource servers to signal to the client that the + authentication event associated with the access token presented with + the request does not meet the authentication requirements of the + resource server. This document also introduces acr_values and + max_age parameters for the Bearer authentication scheme challenge + defined by [RFC6750]. The resource server can use these parameters + to explicitly communicate to the client the required authentication + strength or recentness. + + The client can use that information to reach back to the + authorization server with an authorization request that specifies the + authentication requirements indicated by the protected resource. + This is accomplished by including the acr_values or max_age + authorization request parameters as defined in [OIDC]. + + Those extensions will make it possible to implement interoperable + step up authentication with minimal work from resource servers, + clients, and authorization servers. + +1.1. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This specification uses the terms "access token", "authorization + server", "authorization endpoint", "authorization request", "client", + "protected resource", and "resource server" defined by "The OAuth 2.0 + Authorization Framework" [RFC6749]. + +2. Protocol Overview + + The following is an end-to-end sequence of a typical step up + authentication scenario implemented according to this specification. + The scenario assumes that, before the sequence described below takes + place, the client already obtained an access token for the protected + resource. + + +----------+ +--------------+ + | | | | + | |-----------(1) request ------------------>| | + | | | | + | |<---------(2) challenge ------------------| Resource | + | | | Server | + | Client | | | + | |-----------(5) request ------------------>| | + | | | | + | |<-----(6) protected resource -------------| | + | | +--------------+ + | | + | | + | | +-------+ +---------------+ + | |->| | | | + | | | |--(3) authorization request-->| | + | | | User | | | + | | | Agent |<-----------[...]------------>| Authorization | + | | | | | Server | + | |<-| | | | + | | +-------+ | | + | | | | + | |<-------- (4) access token --------------| | + | | | | + +----------+ +---------------+ + + Figure 1: Abstract Protocol Flow + + 1. The client requests a protected resource, presenting an access + token. + + 2. The resource server determines that the circumstances in which + the presented access token was obtained offer insufficient + authentication strength and/or recentness; hence, it denies the + request and returns a challenge describing (using a combination + of acr_values and max_age) what authentication requirements must + be met for the resource server to authorize a request. + + 3. The client directs the user agent to the authorization server + with an authorization request that includes the acr_values and/or + max_age indicated by the resource server in the previous step. + + 4. Whatever sequence required by the grant of choice plays out; this + will include the necessary steps to authenticate the user in + accordance with the acr_values and/or max_age values of the + authorization request. Then, the authorization server returns a + new access token to the client. The new access token contains or + references information about the authentication event. + + 5. The client repeats the request from step 1, presenting the newly + obtained access token. + + 6. The resource server finds that the user authentication performed + during the acquisition of the new access token complies with its + requirements and returns the representation of the requested + protected resource. + + The validation operations mentioned in steps 2 and 6 imply that the + resource server has a way of evaluating the authentication that + occurred during the process by which the access token was obtained. + In the context of this document, the assessment by the resource + server of the specific authentication method used to obtain a token + for the requested resource is called an "authentication level". This + document will describe how the resource server can perform this + assessment of an authentication level when the access token is a JSON + Web Token (JWT) [RFC9068] or is validated via introspection + [RFC7662]. Other methods of determining the authentication level by + which the access token was obtained are possible, per agreement by + the authorization server and the protected resource, but they are + beyond the scope of this specification. Given an authentication + level of a token, the resource server determines whether it meets the + security criteria for the requested resource. + + The terms "authentication level" and "step up" are metaphors in this + specification. These metaphors do not suggest that there is an + absolute hierarchy of authentication methods expressed in + interoperable fashion. The notion of a level emerges from the fact + that the resource server may only want to accept certain + authentication methods. When presented with a token derived from a + particular authentication method (i.e., a given authentication level) + that it does not want to accept (i.e., below the threshold or level + it will accept), the resource server seeks to step up (i.e., + renegotiate) from the current authentication level to one that it may + accept. The "step up" metaphor is intended to convey a shift from + the original authentication level to one that is acceptable to the + resource server. + + Although the case in which the new access token supersedes old tokens + by virtue of a higher authentication level is common, in line with + the connotation of the term "step up authentication", it is important + to keep in mind that this might not necessarily hold true in the + general case. For example, for a particular request, a resource + server might require a higher authentication level and a shorter + validity, resulting in a token suitable for one-off calls but leading + to frequent prompts: hence, offering a suboptimal user experience if + the token is reused for routine operations. In such a scenario, the + client would be better served by keeping both the old tokens, which + are associated with a lower authentication level, and the new one: + selecting the appropriate token for each API call. This is not a new + requirement for clients, as incremental consent and least-privilege + principles will require similar heuristics for managing access tokens + associated with different scopes and permission levels. This + document does not recommend any specific token-caching strategy: that + choice will be dependent on the characteristics of every particular + scenario and remains application-dependent as in the core OAuth + cases. Also recall that OAuth 2.0 [RFC6749] assumes access tokens + are treated as opaque by clients. The token format might be + unreadable to the client or might change at any time to become + unreadable. So, during the course of any token-caching strategy, a + client must not attempt to inspect the content of the access token to + determine the associated authentication information or other details + (see Section 6 of [RFC9068] for a more detailed discussion). + +3. Authentication Requirements Challenge + + This specification introduces a new error code value for the + challenge of the Bearer authentication scheme's error parameter (from + [RFC6750]) and other OAuth authentication schemes, such as those seen + in [RFC9449], which use the same error parameter: + + insufficient_user_authentication: The authentication event + associated with the access token presented with the request does + not meet the authentication requirements of the protected + resource. + + Note: the logic through which the resource server determines that the + current request does not meet the authentication requirements of the + protected resource, and associated functionality (such as expressing, + deploying and publishing such requirements), is out of scope for this + document. + + Furthermore, this specification defines the following WWW- + Authenticate auth-param values for those OAuth authentication schemes + to convey the authentication requirements back to the client. + + acr_values: A space-separated string listing the authentication + context class reference values in order of preference. The + protected resource requires one of these values for the + authentication event associated with the access token. As defined + in Section 1.2 of [OIDC], the authentication context conveys + information about how authentication takes place (e.g., what + authentication method(s) or assurance level to meet). + + max_age: This value indicates the allowable elapsed time in seconds + since the last active authentication event associated with the + access token. An active authentication event entails a user + interacting with the authorization server in response to an + authentication prompt. Note that, while the auth-param value can + be conveyed as a token or quoted-string (see Section 11.2 of + [RFC9110]), it has to represent a non-negative integer. + + Figure 2 is an example of a Bearer authentication scheme challenge + with the WWW-Authenticate header using: + + * the insufficient_user_authentication error code value to inform + the client that the access token presented is not sufficient to + gain access to the protected resource, and + + * the acr_values parameter to let the client know that the expected + authentication level corresponds to the authentication context + class reference identified by myACR. + + Note that while this specification only defines usage of the above + auth-params with the insufficient_user_authentication error code, it + does not preclude future specifications or profiles from defining + their usage with other error codes. + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer error="insufficient_user_authentication", + error_description="A different authentication level is required", + acr_values="myACR" + + Figure 2: Authentication Requirements Challenge Indicating acr_values + + The example in Figure 3 shows a challenge informing the client that + the last active authentication event associated with the presented + access token is too old and a more recent authentication is needed. + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer error="insufficient_user_authentication", + error_description="More recent authentication is required", + max_age="5" + + Figure 3: Authentication Requirements Challenge Indicating max_age + + The auth-params max_age and acr_values MAY both occur in the same + challenge if the resource server needs to express requirements about + both recency and authentication level. If the resource server + determines that the request is also lacking the scopes required by + the requested resource, it MAY include the scope attribute with the + value necessary to access the protected resource, as described in + Section 3.1 of [RFC6750]. + +4. Authorization Request + + A client receiving a challenge from the resource server carrying the + insufficient_user_authentication error code SHOULD parse the WWW- + Authenticate header for acr_values and max_age and use them, if + present, in constructing an authorization request. This request is + then conveyed to the authorization server's authorization endpoint + via the user agent in order to obtain a new access token complying + with the corresponding requirements. The acr_values and max_age + authorization request parameters are both OPTIONAL parameters defined + in Section 3.1.2.1. of [OIDC]. This document does not introduce any + changes in the authorization server behavior defined in [OIDC] for + processing those parameters; hence, any authorization server + implementing OpenID Connect will be able to participate in the flow + described here with little or no changes. See Section 5 for more + details. + + The example authorization request URI below, which might be used + after receiving the challenge in Figure 2, indicates to the + authorization server that the client would like the authentication to + occur according to the authentication context class reference + identified by myACR. + + https://as.example.net/authorize?client_id=s6BhdRkqt3 + &response_type=code&scope=purchase&acr_values=myACR + + Figure 4: Authorization Request Indicating acr_values + + After the challenge in Figure 3, a client might direct the user agent + to the following example authorization request URI where the max_age + parameter indicates to the authorization server that the user- + authentication event needs to have occurred no more than five seconds + prior. + + https://as.example.net/authorize?client_id=s6BhdRkqt3 + &response_type=code&scope=purchase&max_age=5 + + Figure 5: Authorization Request Indicating max_age + +5. Authorization Response + + Section 5.5.1.1 of [OIDC] establishes that an authorization server + receiving a request containing the acr_values parameter MAY attempt + to authenticate the user in a manner that satisfies the requested + authentication context class reference and include the corresponding + value in the acr claim in the resulting ID Token. The same section + also establishes that, in case the desired authentication level + cannot be met, the authorization server SHOULD include a value + reflecting the authentication level of the current session (if any) + in the acr claim. Furthermore, Section 3.1.2.1 [OIDC] states that if + a request includes the max_age parameter, the authorization server + MUST include the auth_time claim in the issued ID Token. An + authorization server complying with this specification will react to + the presence of the acr_values and max_age parameters by including + acr and auth_time in the access token (see Section 6 for details). + Although [OIDC] leaves the authorization server free to decide how to + handle the inclusion of acr in the ID Token when requested via + acr_values, when it comes to access tokens in this specification, the + authorization server SHOULD consider the requested acr value as + necessary for successfully fulfilling the request. That is, the + requested acr value is included in the access token if the + authentication operation successfully met its requirements; + otherwise, the authorization request fails and returns an + unmet_authentication_requirements error as defined in [OIDCUAR]. The + recommended behavior will help prevent clients getting stuck in a + loop where the authorization server keeps returning tokens that the + resource server already identified as not meeting its requirements. + +6. Authentication Information Conveyed via Access Token + + To evaluate whether an access token meets the protected resource's + requirements, the resource server needs a way of accessing + information about the authentication event by which that access token + was obtained. This specification provides guidance on how to convey + that information in conjunction with two common access-token- + validation methods: + + * the one described in [RFC9068], where the access token is encoded + in JWT format and verified via a set of validation rules, and + + * the one described in [RFC7662], where the token is validated and + decoded by sending it to an introspection endpoint. + + Authorization servers and resource servers MAY elect to use other + encoding and validation methods; however, those are out of scope for + this document. + +6.1. JWT Access Tokens + + When access tokens are represented as JSON Web Tokens (JWTs) + [RFC7519], the auth_time and acr claims (per Section 2.2.1 of + [RFC9068]) are used to convey the time and context of the user- + authentication event that the authentication server performed during + the course of obtaining the access token. It is useful to bear in + mind that the values of those two parameters are established at user- + authentication time and will not change in the event of access token + renewals. See the aforementioned Section 2.2.1 of [RFC9068] for + details. The following is a conceptual example showing the decoded + content of such a JWT access token. + + Header: + + {"typ":"at+JWT","alg":"ES256","kid":"LTacESbw"} + + Claims: + + { + "iss": "https://as.example.net", + "sub": "someone@example.net", + "aud": "https://rs.example.com", + "exp": 1646343000, + "iat": 1646340200, + "jti" : "e1j3V_bKic8-LAEB_lccD0G", + "client_id": "s6BhdRkqt3", + "scope": "purchase", + "auth_time": 1646340198, + "acr": "myACR" + } + + Figure 6: Decoded JWT Access Token + +6.2. OAuth 2.0 Token Introspection + + "OAuth 2.0 Token Introspection" [RFC7662] defines a method for a + protected resource to query an authorization server about the active + state of an access token as well as to determine metainformation + about the token. The following two top-level introspection response + members are defined to convey information about the user- + authentication event that the authentication server performed during + the course of obtaining the access token. + + acr: String specifying an authentication context class reference + value that identifies the authentication context class that was + satisfied by the user-authentication event performed. + + auth_time: Time when the user authentication occurred. A JSON + numeric value representing the number of seconds from + 1970-01-01T00:00:00Z UTC until the date/time of the authentication + event. + + The following example shows an introspection response with + information about the user-authentication event by which the access + token was obtained. + + HTTP/1.1 200 OK + Content-Type: application/json + + { + "active": true, + "client_id": "s6BhdRkqt3", + "scope": "purchase", + "sub": "someone@example.net", + "aud": "https://rs.example.com", + "iss": "https://as.example.net", + "exp": 1639528912, + "iat": 1618354090, + "auth_time": 1646340198, + "acr": "myACR" + } + + Figure 7: Introspection Response + +7. Authorization Server Metadata + + Authorization servers can advertise their support of this + specification by including in their metadata document, as defined in + [RFC8414], the value acr_values_supported, as defined in Section 3 of + [OIDCDISC]. The presence of acr_values_supported in the + authorization server metadata document signals that the authorization + server will understand and honor the acr_values and max_age + parameters in incoming authorization requests. + +8. Deployment Considerations + + This specification facilitates the communication of requirements from + a resource server to a client, which, in turn, can enable a smooth + step up authentication experience. However, it is important to + realize that the user experience achievable in every specific + deployment is a function of the policies each resource server and + authorization server pair establishes. Imposing constraints on those + policies is out of scope for this specification; hence, it is + perfectly possible for resource servers and authorization servers to + impose requirements that are impossible for users to comply with or + that lead to an undesirable user-experience outcome. The + authentication prompts presented by the authorization server as a + result of the method of propagating authentication requirements + described here might require the user to perform some specific + actions such as using multiple devices, having access to devices + complying with specific security requirements, and so on. Those + extra requirements, that are more concerned with how to comply with a + particular requirement rather than indicating the identifier of the + requirement itself, are out of scope for this specification. + +9. Security Considerations + + This specification adds to previously defined OAuth mechanisms. + Their respective security considerations apply: + + * OAuth 2.0 [RFC6749], + + * JWT access tokens [RFC9068], + + * Bearer WWW-Authenticate [RFC6750], + + * token introspection [RFC7662], and + + * authorization server metadata [RFC8414]. + + This document MUST NOT be used to position OAuth as an authentication + protocol. For the purposes of this specification, the way in which a + user authenticated with the authorization server to obtain an access + token is salient information, as a resource server might decide + whether to grant access on the basis of how that authentication + operation was performed. Nonetheless, this specification does not + attempt to define the mechanics by which authentication takes place, + relying on a separate authentication layer to take care of the + details. In line with other specifications of the OAuth family, this + document assumes the existence of a session without going into the + details of how it is established or maintained, what protocols are + used to implement that layer (e.g., OpenID Connect), and so forth. + Depending on the policies adopted by the resource server, the + acr_values parameter introduced in Section 3 might unintentionally + disclose information about the authenticated user, the resource + itself, the authorization server, and any other context-specific data + that an attacker might use to gain knowledge about their target. For + example, a resource server requesting an acr value corresponding to a + high level of assurance for some users but not others might identify + possible high-privilege users to target with spearhead phishing + attacks. Implementers should use care in determining what to + disclose in the challenge and in what circumstances. The logic + examining the incoming access token to determine whether or not a + challenge should be returned can be executed either before or after + the conventional token-validation logic, be it based on JWT + validation, introspection, or any other method. The resource server + MAY return a challenge without verifying the client presented a valid + token. However, this approach will leak the required properties of + an authorization token to an actor who has not proven they can obtain + a token for this resource server. + + As this specification provides a mechanism for the resource server to + trigger user interaction, it's important for the authorization server + and clients to consider that a malicious resource server might abuse + that feature. + +10. IANA Considerations + +10.1. OAuth Extensions Error Registration + + This specification registers the following error value in the "OAuth + Extensions Error Registry" [IANA.OAuth.Params] established by + [RFC6749]. + + Name: insufficient_user_authentication + Usage Location: resource access error response + Protocol Extension: OAuth 2.0 Step Up Authentication Challenge + Protocol + Change controller: IETF + Specification document(s): Section 3 of RFC 9470 + +10.2. OAuth Token Introspection Response Registration + + This specification registers the following values in the "OAuth Token + Introspection Response" registry [IANA.OAuth.Params] established by + [RFC7662]. + + Authentication Context Class Reference: + + Name: acr + Description: Authentication Context Class Reference + Change Controller: IETF + Specification Document(s): Section 6.2 of RFC 9470 + + Authentication Time: + + Name: auth_time + Description: Time when the user authentication occurred + Change Controller: IETF + Specification Document(s): Section 6.2 of RFC 9470 + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + <https://www.rfc-editor.org/info/rfc6749>. + + [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization + Framework: Bearer Token Usage", RFC 6750, + DOI 10.17487/RFC6750, October 2012, + <https://www.rfc-editor.org/info/rfc6750>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +11.2. Informative References + + [IANA.OAuth.Params] + IANA, "OAuth Parameters", + <https://www.iana.org/assignments/oauth-parameters>. + + [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0 incorporating + errata set 1", 8 November 2014, + <https://openid.net/specs/openid-connect-core-1_0.html>. + + [OIDCDISC] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID + Connect Discovery 1.0 incorporating errata set 1", 8 + November 2014, <https://openid.net/specs/openid-connect- + discovery-1_0.html>. + + [OIDCUAR] Lodderstedt, T., "OpenID Connect Core Error Code + unmet_authentication_requirements", 8 May 2019, + <https://openid.net/specs/openid-connect-unmet- + authentication-requirements-1_0.html>. + + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, + <https://www.rfc-editor.org/info/rfc7519>. + + [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", + RFC 7662, DOI 10.17487/RFC7662, October 2015, + <https://www.rfc-editor.org/info/rfc7662>. + + [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 + Authorization Server Metadata", RFC 8414, + DOI 10.17487/RFC8414, June 2018, + <https://www.rfc-editor.org/info/rfc8414>. + + [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 + Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October + 2021, <https://www.rfc-editor.org/info/rfc9068>. + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., + Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of + Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, + September 2023, <https://www.rfc-editor.org/info/rfc9449>. + +Acknowledgements + + I wanted to thank the Academy, the viewers at home, the shampoo + manufacturers, etc. + + This specification was developed within the OAuth Working Group under + the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with + Paul Wouters and Roman Danyliw serving as Security Area Directors. + Additionally, the following individuals contributed ideas, feedback, + corrections, and wording that helped shape this specification: Caleb + Baker, Ivan Kanakarakis, Pieter Kasselman, Aaron Parecki, Denis + Pinkas, Dima Postnikov, and Filip Skokan. + + Some early discussion of the motivations and concepts that + precipitated the initial draft version of this document occurred at + the 2021 OAuth Security Workshop. The authors thank the organizers + of the workshop (Guido Schmitz, Steinar Noem, and Daniel Fett) for + hosting an event that is conducive to collaboration and community + input. + +Authors' Addresses + + Vittorio Bertocci + Auth0/Okta + Email: vittorio@auth0.com + + + Brian Campbell + Ping Identity + Email: bcampbell@pingidentity.com |