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

[Denis <[e-mail]>]

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