Skip to content

Adding first draft of authentication/authorization documentation #98

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Adding first draft of authentication/authorization documentation #98

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions auth/readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# 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.

## Requirements

__Authorization__: A user of a TEA service may get access to all objects (leaf, collections) and
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.

In order to get interoperability between clients and servers implementing the protocol, the
specification focuses on the authentication. After successful authentication, the authorization
may be implemented in multiple ways - on various levels of the API - depending on what information
the user can access.
Comment on lines +17 to +20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we specify that authorization should not require additional work on the part of an authenticated client?

What I mean is that clients should have a single bearer token to authenticate to the server, instead of separate tokens for each resource they request.


As an example, one implementation may publish all information about existing artefacts and software
versions openly, but restrict access to artefacts to those that match the customers installation.
Another implementation can implement a filter that does not show products and versions ("leafs") that
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.

## HTTP bearer token auth

The API will support HTTP bearer token in the __Authorization:__ http header.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally keep this out of scope. In some machine-to-machine scenarios, using Mutual TLS (mTLS) may make more sense. Thus I would suggest leaving out this block in favor of just saying that it is up to the implementor.

How the token is aquired is out of scope for this
specification, as is the potential content of the token.

As an example the token can be downloaded from a customer support portal with a long-term
validity. This token is then installed into the software transparency platform (the TEA client)
and used to automatically retrieve software transparency artefacts.

## References

- RFC 6750: The Oauth 2.0 Authorization Framework: Bearer Token Usage (https://www.rfc-editor.org/rfc/rfc6750)