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 <aa...@parecki.com>:
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 <dick.ha...@gmail.com
<mailto:dick.ha...@gmail.com>> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ 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
