Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 6e5aab87c35088b1fdc90e09253b226a76aad502 Inspect the deploy log: Browse the preview:
Draft -07 states in section 13 (Privacy Considerations): Given this statement, it is unfortunate that the Guidelines (Section 7) given in RFC 6973 have not been followed and thus most questions have been left unanswered. In particular, section 7.1 states: The current text is lacking to answer to the above questions. Some comments on the proposed text 1/ The proposed text does not make any difference whether rights or attributes are supported by the RS to allow performing operations on a given resource under the control of an RS. However, major differences would need to be made. They are detailed in draft-pinkas-gnap-core-protocol-00. See : 2/ 13.1.2. Surveillance by the Authorization Server Unfortunately, the core protocol does not support any feature to achieve that goal. 3/ The text continues with: Avoiding the use of the "locations" object is by no means a way to solve this issue. One year ago, a mechanism to hide to the AS to identity of the RS has been explained on the mailing list. It allows to target the access token to the intended RS while hiding to the AS the value of the identifier of the RS. It is detailed in draft-pinkas-gnap-core-protocol-00. See the "hidden_url" field of the access token on page 9. 4/ The text continues with: This is insufficient: in addition, the AS SHALL not make available a token introspection end-point. 5/ Section 13.3 (Intrusion) deals with denial of service which has nothing to do with privacy. 6/ The last paragraph of this section states: This leaves the door wide opened on how a RS can verify that an access token is associated (or not) with the right (short-term or long-term) user account. This case is addressed in details in draft-pinkas-gnap-core-protocol-00. See the field "buid" which is a "binding user identifier" field of the access token on page 9. 7/ The text continues with: 8/ The text continues with: This is wrong. Since draft -07 considers that "The format and contents of subject identifiers are intentionally not defined by GNAP", it is unable to provide any solution. This case is addressed in details in draft-pinkas-gnap-core-protocol-00. See the field "buid" which is a "binding user identifier" field of the access token on page 9.

Discussion:
12. <del> [[ TBD: There are a lot of privacy considerations to add. ]] Handles are passed between parties and therefore should not contain any private data. When user information is passed to the client instance, the AS needs to make sure that it has the permission to do so. </del> <ins> The privacy considerations in this section are modeled after the list of privacy threats in [RFC6973], "Privacy Considerations for Internet Protocols", and either explain how these threats are mitigated or advise how the threats relate to GNAP. 12.1. Surveillance is the observation or monitoring of an individual's communications or activities.  Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. GNAP assumes the TLS protection used throughout the spec is intact. Without the protection of TLS, there are many points throughout the use of GNAP that would lead to possible surveillance. 12.1.1. The purpose of GNAP is to authorize clients to be able to access information on behalf of a user.  So while it is expected that the client may be aware of the user's identity as well as data being fetched for that user, in some cases the extent of the client may be beyond what the user is aware of.  For example, a client may be implemented as multiple distinct pieces of software, such as a logging service or a mobile app that reports usage data to an external backend service. 12.1.2. The role of the authorization server is to manage the authorization of client instances to protect access to the user's data.  In this role, the authorization server is by definition aware of each authorization of a client instance by a user.  When the authorization server shares user information with the client instance, it needs to make sure that it has the permission from that user to do so. Additionally, as part of the authorization grant process, the authorization server may be aware of which resource servers the client intends to use an access token at.  However, it is possible to design a system using GNAP in which this knowledge is not made available to the authorization server, such as by avoiding the use of the "locations" object in the authorization request. If the authorization server's implementation of access tokens is such that it requires a resource server call back to the authorization server to validate them, then the authorization server will be aware of which resource servers are actively in use and by which users and which clients.  To avoid this possibility, the authorization server would need to structure access tokens in such a way that they can be validated by the resource server without notifying the authorization server that the token is being validated. 12.2. Several parties in the GNAP process are expected to persist data at least temporarily, if not semi-permanently, for the normal functioning of the system.  If compromised, this could lead to exposure of sensitive information.  This section documents the potentially sensitive information each party in GNAP is expected to store for normal operation.  Naturally it is possible that any party is storing information for longer than technically necessary of the protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for user indefinitely, in order to be able to include them in the responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. The client is expected to store its client instance key indefinitely, in order to authenticate to the authorization server for the normal functioning of the GNAP flows.  Additionally, the client will be temporarily storing artifacts issued by the authorization server during a flow, and these artifacts SHOULD be discarded by the client when the transaction is complete. The resource server is not required to store any state for its normal operation.  Depending on the implementation of access tokens, the resource server may need to cache public keys from the authorization server in order to validate access tokens. 12.3. Intrusion refers to the ability of various parties to send unsolicited messages or cause denial of service for unrelated parties. If the resource owner is different from the end user, there is an opportunity for the end user to cause unsolicited messages to be sent to the resource owner if the system prompts the resource owner for consent when an end user attempts to access their data. The format and contents of subject identifiers are intentionally not defined by GNAP.  If the authorization server uses values for subject identifiers that are also identifiers for communication channels, (e.g. an email address or phone number), this opens up the possibility for a client to learn this information when it was not otherwise authorized to access this kind of data about the user. 12.4. The threat of correlation is the combination of various pieces of information related to an individual in a way that defies their expectations of what others know about them. 12.4.1. The biggest risk of correlation in GNAP is when an authorization server returns stable consistent user identifiers to multiple different applications.  In this case, applications created by different parties would be able to correlate these user identifiers out of band in order to know which users they have in common. The most common example of this in practice is tracking for advertising purposes, such that client A shares their list of user IDs with an ad platform that is then able to retarget ads to applications created by other parties.  In contrast, a positive example of correlation is a corporate acquisition where two previously unrelated clients now do need to be able to identify the same user between the two clients. 12.4.2. Unrelated resource servers also have an opportunity to correlate users if the authorization server includes stable user identifiers in access tokens or in access token introspection responses. In some cases a resource server may not actually need to be able to identify users, (such as a resource server providing access to a company cafeteria menu which only needs to validate whether the user is a current employee), so authorization servers should be thoughtful of when user identifiers are actually necessary to communicate to resource servers for the functionining of the system. 12.4.3. Clients are expected to be identified by their client instance key. If a particular client instance key is used at more than one authorization server, this could open up the possibility for multiple unrelated authorization servers to correlate client instances.  This is especially a problem in the common case where a client instance is used by a single individual, as it would allow the authorization servers to correlate that individual between them.  If this is a concern of a client, the client should use distinct keys with each authorization server. 12.5. Throughout many parts of GNAP, the parties pass shared references between each other, sometimes in place of the values themselves.  For example the "interact_ref" value used throughout the flow.  These references are intended to be random strings and should not contain any private or sensitive data that would potentially leak information between parties. </ins> 13.  References