Clarifications based on pull request feedback

- MTLS usage
- Token usage

Signed-off-by: Olle E. Johansson <[email protected]>

Author: oej

auth/readme.md

@@ -1,8 +1,5 @@
 # Transparency Exchange API - Authentication and authorization
 
-
-**NOTE**: _This is a proposal for the WG_
-
 This document covers authentication and authorization on the consumer side
 of a TEA service - the discovery and download of software transparency artefacts.
 
@@ -12,7 +9,8 @@ __Authorization__: A user of a TEA service may get access to all objects (leaf,
 artefacts or just a subset, depending on the publisher of the data. Authorization is connected
 to __authentication__. 
 
-The level of authorization is up to the implementer of the TEA implementation and the publisher.
+The level of authorization is up to the implementer of the TEA implementation and the publisher,
+whether an identity gets access to all objects in a service or just a subset.
 
 In order to get interoperability between clients and servers implementing the protocol, the
 specification focuses on the authentication. After successful authentication, the authorization
@@ -27,6 +25,15 @@ the customer has not aquired.
 For most Open Source projects, implementing authentication - setting up accounts and managing
 authorization - does not make much sense, since the information is usually in the open any way.
 
+This specification does not impose any requirement on authentication on a TEA service. But should
+the provider implement authentication, two methods are supported in order to promote interoperability.
+
+* HTTP Bearer Token Authentication
+* Mutual TLS with verifiable client and server certificates
+
+A client may use both HTTP bearer token auth and TLS client certificates
+when accessing multiple TEA services. It is up to the service provider to select authentication.
+
 ## HTTP bearer token auth
 
 The API will support HTTP bearer token in the __Authorization:__ http header.
@@ -37,6 +44,17 @@ As an example the token can be downloaded from a customer support portal with a
 validity. This token is then installed into the software transparency platform (the TEA client)
 and used to automatically retrieve software transparency artefacts.
 
+For each TEA service, one bearer token is needed. The token itself (or the backend) should
+specify authorization for the token.
+
+## Mutual TLS
+
+For Mutual TLS the client certificates will be managed by the service and provided
+in a service-specific way. Clients should be able to configure a separate client certificate
+(and private key) on a per-service level, not assuming that a client certificate
+for one service is trusted anywhere else.
+
 ## References
 
-- RFC 6750: The Oauth 2.0 Authorization Framework: Bearer Token Usage (https://www.rfc-editor.org/rfc/rfc6750)
+* RFC 6750: The Oauth 2.0 Authorization Framework: Bearer Token 
+  Usage (https://www.rfc-editor.org/rfc/rfc6750)