Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

[Filip Skokan <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> <[e-mail]>
> :
>
> 
> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>