Commit 9ccd74f6 authored by Nikos Fotiou's avatar Nikos Fotiou
Browse files

Description modification

parent 78a74e3b
......@@ -13,50 +13,15 @@ by N. Fotiou, V.A. Siris, G.C. Polyzos, appeared in 30th International Conferenc
on Computer Communications and Networks (ICCCN). You can view a video presentation
of this paper [here](https://www.youtube.com/watch?v=B6biTo8w5zw)
## Description
ZeroTrustVC is an access control solution that relies on widely used standards,
composed of a VC issuer and a VC verifier.
The VC issuer is an OAuth 2.0 authorization
server extended with VC issuing capabilities. Issued VCs are encoded as JWT and signed
using JWS, improving compatibility and integration with existing tools. ZeroTrustVC
consider VCs that describe the *capabilities* of a client over a protected resource.
Additionally, ZeroTrustVC VC issuer can perform VC revocations.
The VC verifier is an HTTP proxy, which is able to verify the validity and the
ownership of a VC. Additionally, the VC verifier validates whether or not
a VC can be used for executing a particular request.
ZeroTrustVC provides two VC verifiers: a generic Python3-based, acting as transparent proxy, and a .NET
core framework authorization middleware for securing .NET web apps.
Users interact with ZeroTrustVC using standard OAuth 2.0 flows. ZeroTrustVC facilitates
ZeroTrustVC facilitates
capabilities-based access control, supports efficient VC revocation, and enables
"strong authentication and authorization of every access request" enabling resource
access over public, untrusted networks, aka Zero -Trust Architectures (ZTAs).
access over public, untrusted networks, aka Zero -Trust Architectures (ZTAs).
## Solution overview
The following figure illustrates the modules of the ZeroTrustVC component.
![ZeroTurstVC architecture](architecture.png "ZeroTurstVC architecture")
A typical authorization flow in ZeroTrustVC includes the following steps
### Issuer configuration
With this step, a resource owner configures the issuer with policies
that specify the access rights that correspond to a client. Clients are identified
using a public key (later on this project we will consider cases where clients are
identified by a Decentralized Identifier).
### VC request and issuance
With this step, a client requests from the issuer a VC. A client request
is in essence an [OAuth 2.0 access token request using the client
credentials grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4). The
client proof possession of the corresponding public key using OAuth 2.0 [Demonstrating
Proof-of-Possession at the Application Layer (DPoP)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04).
The issuer responds with a VC [encoded as JWT](https://www.w3.org/TR/vc-data-model/#jwt-encoding).
The following figure gives a high level overview of ZeroTurstVC project.
![ZeroTurstVC overview](overview.png "ZeroTurstVC overview")
### Resource request
A client requests an HTTP resource by including in its request the received
JWT-encoded VC and the corresponding [DPoP proof](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04#section-7).
The request is received by the verifier that acts as an HTTP proxy. The verifier
validates the included VC and proof, and if the validation succeeds, it forwards
the request to the actual resource.
\ No newline at end of file
ZeroTurstVC considers users of an enterprise wishing to access an HTTP-based *protected resource*
using their *client* applications. Both clients and the protected resource may
be located in an network outside the administrative realm of the enterprise.
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment