Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : 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 .
Paragraph (version A):
Handles are passed between parties and therefore should not contain
any private data.
Paragraph (version A):
When user information is passed to the client instance, the AS needs
to make sure that it has the permission to do so.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Intrusion refers to the ability of various parties to send
unsolicited messages or cause denial of service for unrelated
parties.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.