Denis, PAR is arguably not the document that should retrofit OAuth 2.0 with a full blown Privacy Consideration section. Now, do you find the draft introduces anything new from a privacy perspective? Does the AS get anything other than what it already does via the authorization_endpoint today?
For the record i'm not arguing OAuth 2.0 should be without privacy considerations, i'm just saying - if it did, or rather, regardless if it does or doesn't - PAR does not expand on those in any way. S pozdravem, *Filip Skokan* On Tue, 11 Aug 2020 at 17:17, Denis <[email protected]> wrote: > Hi Filip, > > I don’t think there’s anything new introduced in PAR that would alter > existing status quo of privacy consiserations. > As such if privacy consideration was to be added for completeness it > should be along the lines of “this document > does not expand on or otherwise alter the privacy considerations” or > “there are no new privacy considerations introduced by this document”. > > OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was > issued before RFC 6973 (Privacy Considerations for Internet Protocols) > existed. > > I browsed through the RFCs published by this WG and the guidance provided > in RFC 6973 has not really be used and followed. > > So adding no text to nearly zero text will not help that much. I believe > that a Privacy considerations section will be added to the OAuth 2.1 draft. > While doing that exercise, a shorter version of it could be included in > PAR. > > Hereafter is my detailed analysis: > > RFC 6973 (Privacy Considerations for Internet Protocols) has been issued > in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy > Considerations section. > > This is the case for : > - RFC 6749 (The OAuth 2.0 Authorization Framework) - RFC > 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) - > RFC 6755 (An IETF URN Sub-Namespace for OAuth) - RFC 6819 (OAuth > 2.0 Threat Model and Security Considerations) For RFCs issued after RFC > 6973, six of them don't have a have a Privacy Considerations section. This > is the case for: > - *RFC 7009 *(OAuth 2.0 Token Revocation) - * RFC 7519* > updated by RFC 8725 (JSON Web Token Best Current Practices) - *RFC > 7636* (Proof Key for Code Exchange by OAuth Public Clients) - *RFC > 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations > section - *RFC 8414 *(OAuth 2.0 Authorization Server Metadata) - > *RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a > Privacy Considerations section. They are enumerated below, with a copy of > these sections. - *RFC 7521* (Assertion Framework for OAuth 2.0 > Client Authentication and Authorization Grants) 8.4. Privacy > Considerations An assertion may contain privacy-sensitive information > and, to prevent disclosure of such information to unintended parties, > should only be transmitted over encrypted channels, such as TLS. In > cases where it is desirable to prevent disclosure of > certain information to the client, the assertion (or portions of it) > should be encrypted to the authorization server. Deployments should > determine the minimum amount of information necessary to complete the > exchange and include only > such information in the assertion. In some cases, the Subject identifier > can be a value representing an anonymous or pseudonymous > user, as described in Section 6.3.1. - *RFC 7522* (Security > Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client > Authentication and Authorization Grants 7. Privacy Considerations > > A SAML Assertion may contain privacy-sensitive information and, to prevent > disclosure of such information to unintended parties, > should only be transmitted over encrypted channels, such as Transport Layer > Security (TLS). In cases where it is desirable to prevent > disclosure of certain information to the client, the Subject and/or > individual attributes of a SAML Assertion should be encrypted to the > authorization server. > > Deployments should determine the minimum amount of information necessary to > complete the exchange and include only that information > in an Assertion (typically by limiting what information is included in an > <AttributeStatement> or by omitting it altogether). In some cases, > the Subject can be a value representing an anonymous or pseudonymous user, as > described in Section 6.3.1 > <https://tools.ietf.org/html/rfc7522#section-6.3.1> of the OAuth Assertion > Framework [RFC7521 <https://tools.ietf.org/html/rfc7521>]. > > - *RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client > Authentication and Authorization Grants 7. Privacy Considerations A JWT > may contain privacy-sensitive information and, to prevent disclosure of > such information to unintended parties, should only be transmitted > over encrypted channels, such as Transport Layer Security (TLS). In > cases where it is desirable to prevent disclosure of certain information to > the client, > the JWT should be encrypted to the authorization server. Deployments > should determine the minimum amount of information necessary to complete > the exchange and include only such claims in the JWT. > In some cases, the "sub" (subject) claim can be a value representing an > anonymous or pseudonymous user, as described in Section 6.3.1 of > the OAuth Assertion Framework [RFC7521]. - *RFC 7591* (OAuth 2.0 > Dynamic Client Registration Protocol) 6. Privacy Considerations As the > protocol described in this specification deals almost exclusively with > information about software and not people, there are very few > privacy concerns for its use. The notable exception is the "contacts" > field as defined in Section 2, which contains contact information for > the developers or other parties responsible for the client software. These > values are intended to be displayed to end- users and will be available > to the administrators of the authorization server. As such, the > developer may wish to provide an email address or other contact information > expressly > dedicated to the purpose of supporting the client instead of using their > personal or professional addresses. Alternatively, the developer may > wish > to provide a collective email address for the client to allow for > continuing contact and support of the client software after the developer > moves on and > someone else takes over that responsibility. In general, the metadata for > a client, such as the client name and software identifier, are common > across all instances of a piece of client software > and therefore pose no privacy issues for end-users. Client identifiers, on > the other hand, are often unique to a specific instance of a client. > For clients such as web sites that are used by many users, there may not > be significant privacy concerns regarding the client identifier, but for > clients > such as native applications that are installed on a single end-user's > device, the client identifier could be uniquely tracked during OAuth 2.0 > transactions > and its use tied to that single end-user. However, as the client > software still needs to be authorized by a resource owner through an OAuth > 2.0 > authorization grant, this type of tracking can occur whether or not the > client identifier is unique by correlating the authenticated resource owner > with > the requesting client identifier. Note that clients are forbidden by this > specification from creating their own client identifier. If the client > were able to do so, an individual client instance > could be tracked across multiple colluding authorization servers, leading > to privacy and security issues. Additionally, client identifiers are > generally issued > uniquely per registration request, even for the same instance of software.. > In this way, an application could marginally improve privacy by > registering > multiple times and appearing to be completely separate applications. However, > this technique does incur significant usability cost in the form of > requiring > multiple authorizations per resource owner and is therefore unlikely to be > used in practice. - *RFC 7592* (OAuth 2.0 Dynamic Client > Registration Management Protocol) 6. Privacy Considerations This > specification poses no additional privacy considerations beyond those > described in the core "OAuth 2.0 Dynamic Client Registration Protocol" > [RFC7591]. - *RFC 7662 *(OAuth 2.0 Token Introspection) 5. Privacy > Considerations The introspection response may contain privacy-sensitive > information such as user identifiers for resource owners. When this is > the case, > measures MUST be taken to prevent disclosure of this information to > unintended parties. One method is to transmit user identifiers as opaque > service-specific > strings, potentially returning different identifiers to each protected > resource. If the protected resource sends additional information about > the client's request to the authorization server (such as the client's IP > address) using an extension > of this specification, such information could have additional privacy > considerations that the extension should detail. However, the nature and > implications of such > extensions are outside the scope of this specification. Omitting > privacy-sensitive information from an introspection response is the > simplest way of minimizing privacy issues. - *RFC 7800* > (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 5. Privacy > Considerations A proof-of-possession key can be used as a correlation > handle if the same key is used with multiple parties. Thus, for privacy > reasons, it is recommended > that different proof-of-possession keys be used when interacting with > different parties. - *RFC 8176* (Authentication Method Reference > Values) 4. Privacy Considerations The list of "amr" claim values > returned in an ID Token reveals information about the way that the end user > authenticated to the identity provider. > In some cases, this information may have privacy implications. While this > specification defines identifiers for particular kinds of credentials, it > does not define how these credentials are stored or protected. > For instance, ensuring the security and privacy of biometric credentials > that are referenced by some of the defined Authentication Method Reference > values is beyond the scope of this specification. - *RFC 8693* > (OAuth 2.0 Token Exchange) 6. Privacy Considerations Tokens employed in > the context of the functionality described herein may contain > privacy-sensitive information and, to prevent disclosure > of such information to unintended parties, MUST only be transmitted over > encrypted channels, such as Transport Layer Security (TLS). > In cases where it is desirable to prevent disclosure of certain > information to the client, the token MUST be encrypted to its intended > recipient. > Deployments SHOULD determine the minimally necessary amount of data and > only include such information in issued tokens. In some cases, > data minimization may include representing only an anonymous or > pseudonymous user. - *RFC 8705* (OAuth 2.0 Mutual-TLS Client > Authentication and Certificate-Bound Access Tokens) 8. Privacy > Considerations In TLS versions prior to 1.3, the client's certificate is > sent unencrypted in the initial handshake and can potentially be used by > third parties > to monitor, track, and correlate client activity. This is likely of > little concern for clients that act on behalf of a significant number of > end users > because individual user activity will not be discernible amidst the client > activity as a whole. However, clients that act on behalf of a single end > user, > such as a native application on a mobile device, should use TLS version > 1.3 whenever possible or consider the potential privacy implications of > using mutual TLS on earlier versions. - *RFC 8707* (Resource > Indicators for OAuth 2.0) 4. Privacy Considerations In typical OAuth > deployments the authorization sever is in a position to observe and track a > significant amount of user and client behavior. > It is largely just inherent to the nature of OAuth, and this document does > little to affect that. In some cases, however, such as when access token > introspection is not being used, use of the resource parameter defined > herein may allow for tracking behavior at a somewhat more granular > and specific level than would otherwise be possible in its absence. > > Denis > > > > > Filip > > Odesláno z iPhonu > > 10. 8. 2020 v 19:21, Aaron Parecki <[email protected]> <[email protected]> > : > > > I agree that there is nothing unique to PAR that would justify adding the > privacy considerations mentioned to that draft. I wouldn't oppose adding a > privacy considerations section to OAuth 2.1 though. > > Aaron > > > On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <[email protected]> wrote: > >> In the PAR meeting today, Denis requested there be a privacy >> considerations section in PAR. I don't think there is anything specific in >> PAR that would change the privacy considerations of OAuth, and am checking >> if there is WG interest, and consensus, on including a Privacy >> Considerations section in the OAuth 2.1 draft. >> >> /Dick >> ᐧ >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
