Both of the automated interfaces currently in use (TDA and SFTP) depend on older technologies. The future DAS service should be upgraded to a more modern technology, which will simplify the implementation for offices, improve security and authentication mechanisms, and potentially allow for faster document exchange.

A new REST API is proposed to

modernise the automated interfaces between offices and WIPO DAS:

• REST Web Services.

• OpenID Connect and asymmetric encryption for unpublished document content to secure the exchange process and content

• Warning
  title Access restricted to DAS working group
  a.1.- YAML File for WIPO DAS API.

API Security

For advanced API Security, the FAPI (Financial grade API) – Part 2 standard adds an extra-layer on top of OAuth2.0 and OIDC.

1. private_key_jwt, if the client sends its credentials as a JWT.
2. tls_client_auth, if the client uses a CA-signed certificate for mutual TLS authentication.
3. self_signed_tls_client_auth, if the client uses a self-signed certificate for mutual TLS authentication. 

Access control implementation

To allow safe, secure and trustable authentication, DAS API will have to implement one of the authentication permitted by FAPI part 2. In order not to the implementation of the backend infrastructure too complex, the proposed implementation will only support the private_key_jwt authentication method. The private_key_jwt authentication is based on the asymmetric key signature of the login information, those details – login info + signature - are sent to the authorization server which returns an access token if valid. The access token can then be used to call the DAS API.

The following controls must be enforced to guaranty the same level of security than the TDA VPN connection

Network access-control

Decrease the threat surface and avoid data exfiltration:

1. Restrict communication between WIPO and IP Offices with white listed IP addresses
2. Perform egress/ingress filtering on the approved protocols to avoid data exfiltration.
3. Achieve non-disclosure countermeasure and information protection in transit by enabling TLS1.2 encryption.

API mandatory controls 

Protect access to API

1. API DDOS protection
2. API –Threat protection

Possible setups

DAS protocol necessitates bi-directional communication between offices and WIPO, in practical terms it means that offices must also support private_key_jwt authentication. To ease integration and give freedom to office to choose, we propose two possible setups:

1. WIPO authorization server setup

   Office will use the WIPO authorization server infrastructure for authentication:
   Inbound traffic: whenever a call is received from the WIPO central DAS service the office will have to contact and verify the token against the WIPO authorization server.
   Outbound traffic: office will authenticate using its client id registered in WIPO authorization server and will use the returned access_token to call the WIPO DAS API.
   
   

   draw.io Diagram
   border true diagramName WIPO authorization server simpleViewer false width 600 links auto tbstyle top lbox true diagramWidth 721 revision 1

   
   

   
   

2. Mutual authorization server setup

   Office wants to take care of the authentication by itself consequently provides the private_key_jwt authentication.
   Inbound traffic: The WIPO central DAS service will authenticate against a client id registered in the office authorization server and will use the returned access_token to call the office DAS API 
   Outbound traffic: office will authenticate using its client id registered in WIPO authorization server and will use the returned access_token to call the WIPO DAS API.
   
   

   draw.io Diagram
   border true diagramName Mutual authorization servers simpleViewer false width 600 links auto tbstyle top lbox true diagramWidth 641 revision 1