Authenticating Attributes / Identity Providers

[mrinalwadhwa]

Related to #2621

Authentication: the process where one entity gains assurances about the attributes of another entity.

These assurances may be:

1. self assurances by the entity whose attributes are being authenticated

   a. Proof of possession of private_key during a secure channel handshake authenticates the public_key attribute of an entity.
   b. Proof of Rotation/Revocation of public keys should be a self assurance
   c. An address at which an entity is available to respond may be a self assurance

2. assurances from a third-party that is considered a trusted authority on one or more attributes.

   We may consider the project manager of project Green the trusted authority on which other identities are members of the green project and what roles they play on the project. So to authenticate the project=green, role=reader set of attributes:

   a. we may talk directly to the project manager and ask them for a list of project members and their roles
   b. or we may get a signed credential (like an x509 cert) from some other means that carries a signature by the project manager attesting to a certain identifier possessing a set of other attributes.
   c. or we may get a bearer credential (like a bearer token) that is issued by the trusted authority and proof of possession of that credential may prove a set of attributes assured by the trusted authority.

   In cases a or b we need to have pre-established identifier=6b2edb..,public_key=6b2edb..,project=green,role=project_manager

   In case c we need to have pre-established identifier=6b2edb..,token_validation_mechanism={...},project=green,role=project_manager

   Now the problem has transitioned from "how to authenticate attributes of project members" into "how to authenticate attributes of project managers" .. we may have multiple levels of this transition but eventually every node will need to be initialized with one or more trust anchors.

Authentication of Attributes in itself is an Authentication and Authorization problem.

• who are we talking to and what are their authenticated attributes
• what attributes of themselves or some other entity are they authorized to tell us about

In #2621 I proposed that we should have a place to store Authenticated Attributes of Known Identities. Let's say we call this the Identities table.

To extend that design further, I propose that a we should have pluggable Identity Providers.

An Identity Provider:

1. Is initialized with one or more trust anchors.
2. Implements some mechanism for authenticating attributes using these trust anchors.
3. Is authorized to write a subset of possible attributes to the Identities table.

---

Some examples of possible identity providers:

An identity provider that

• is initialized with a JWT Signing Public Key / Cert of
• supports various OAuth 2.0 & OIDC workflows that result in a signed JWT access token & id token
• is authorized to write attributes that can be fetched using the resulting id token to the Identities table.
• this could be used to integrate with any external identity provider that support OAuth 2.0 & OIDC like Azure AD, Auth0, Okta, Amazon Cognito, Google etc.
• it would also work in cases where the external identity provider has other upstream identity providers - for example Auth0 may have Google or Github upstream

An identity provider that

• is initialized with the public key of a Certificate Authority of a PKI
• authenticates attributes by validating signatures on x509 certs issued by the Certificate Authority
• this would allow us to plug into external PKIs

An identity provider that

• is initialized with the public key of a project manager and a route to make a secure channel with the project manager
• connects with the project manager and simply assumes an attribute to be authenticated if the project manager says so.

An identity provider that

• is initialized with a address to validate bearer tokens/credentials
• stores a preconfigured set of attributes if a valid bearer token is presented

etc.

Let's use the conversation below to explore what it would take to implement such pluggable Identity Providers.
What would their API look like?