Question about Integrating External Authorization in Signify-TS API for KERIA Agent Access

[t-kanuma]

I want to place a reverse proxy to validate requests and verify access authorization when accessing the KERIA agent. Does signify-ts API provide any ways to include external information (such as an authorization token) in the request, for example, by adding it to the headers?

[2byrds]

Hi @t-kanuma Signify-ts and KERIA use signed headers for all operations between the controller and agent, making a token unnecessary. Token based systems are less secure as they provide additional attack vectors.

signify-ts/src/keri/app/clienting.ts

Line 169 in 1e451d1

async fetch(

[kentbull]

SignifyTS and KERIA use a signed everything architecture, so every request is signed. This is the foundation of a zero trust architecture. Zero trust means do not blindly trust anything like an authorization token. Instead you always verify. What are you verifying? The signature on each message, which in this case is a request.

Bearer token architectures like OAuth, JWT, OpenID Connect, and similar are antithetical in security posture as compared to KERI. So it would defeat the entire purpose of using KERI (SignifyTS and KERIA) if you were to use the comparatively low security approach of authorization tokens.

All requests between SignifyTS and KERIA are already validated and access authorization is checked via HTTP message signature by KERIA on each request. So no additional checking between those two components is necessary. If the message signature verifies for KERIA then it can only have come from the correct Signify client.

Yet, to fully answer your external information question there is no current way to add in another HTTP header to the HTTP messages between SignifyTS and KERIA. That could be exposed in Signify though such has not been done yet.

It seems you are asking about communication between SignifyTS and KERIA, which as I said, is already highly secure and properly validated.

If, instead, you are wondering how to integrate the zero trust architecture of Signify and KERIA into your target architecture then you need at least two things, a CESR parser and a persistent memory of key event logs (KELs) for key histories and transaction event logs (TELs) for credential states.

To accomplish a similar goal of role based authorization with KERI and ACDC you have a few options:

1. Store a role cache in your edge server (reverse proxy or whatever performs authorization checking in your architecture) that is keyed by KERI identifier, an autonomic identifier (AID). Use this role cache to permit or deny actions. You could sign an HTTP header with Signify and route it to your non-KERI infrastructure and have your non-KERI infrastructure perform HTTP signature verification. This extends the zero trust benefits to the edge of your architecture. We have not talked about witnesses and watchers yet, just identifiers and signatures.

2. Add CESR stream parsing awareness and a full set of KERI and ACDC cryptographic primitives to your architecture so you can parse and validate KELs and TELs and thereby use role grants in ACDC credentials that are checked by each individual component for a given action. Being able to parse a CESR stream with each component in your architecture would allow you to have a KERI identity via Signify or KERIA pass its CESR stream of its identity and credentials when it "registers" for an account or is otherwise recognized by your system. You could cache this in a Redis or other key value store, or store it locally in each service that performs role checking. This extends the benefits of zero trust throughout your architecture beyond your edge. You could make granting a role be memorialized in an ACDC credential. However, this would mean you need to track revocation state, which you as the issuer would always know because you issued the credential. You would just need to publish that revocation state to the location each service checks in order to know if an identity can perform a given action.

3. Run your own witness and watcher infrastructure where you watch the latest key state (KELs) and credential state (TELs) of the identities interacting with you and have your authorization workflow rely on the watchers to know whether authorizations in credentials have been issued or revoked. Using witnesses and watchers protects you against maliciously forked key history, otherwise known as duplicity.

4. The final point on authorization is using a delegated identifier architecture to indicate that an identity is authorized to perform a given set of actions on behalf of its parent identity. This is more advanced and you likely don't need it up front, yet can be very useful and is more scalable.

This is a long answer to your question of authorization and validation. To match the existing workflow of validating a JWT at and edge of your architecture in something like a reverse proxy I would go with the first option of the role cache and signature verification as this is the least work. It is also the least protection. The next best option is to perform full KEL and TEL validation yet you need a full CESR parser and set of cryptographic primitives to perform that validation. Signify TS is three to five weeks away of serious effort from having a full CESR parser. It already has most of the cryptographic primitives.

Does this answer your question?

[kentbull]

I made a small mistake in my response I just fixed. There should have been a "do not" in front of "blindly trust"

[t-kanuma]

@2byrds , @kentbull

Thank you for your response.

First, I believe I have at least some understanding of the philosophical differences between KERI and existing identity systems like OIDC/OID4VC. Also, I apologize for not providing enough background for my question.

The scenario I have in mind is as follows: Suppose a company A sets up a KERIA Agent within its system infrastructure. If no additional measures are taken, I assume that anyone who gains access to that environment could interact with the KERIA Agent. In other words, new unique AIDs/KELs could be created arbitrarily.

From a security perspective, I believe it would be better to prevent this, which is why I asked the question. I would appreciate your thoughts on this issue, as well as any potential countermeasures.

(A slightly unrelated point, but for comparison: In Hyperledger Aries, which implements DIDComm, the Web Agent provides a REST API, allowing access from an application backend, making access control manageable. On the other hand, in implementations like DWN (Web5), where the frontend application directly accesses the backend Agent/Node—similar to Signify-ts and KERIA—I had the same concern.)

Additionally, I have a follow-up question. You mentioned that access from Signify-ts to KERIA is secure, but does this also include the aspect of encrypted communication?

My understanding was that communication between Agents is encrypted, even over HTTP, due to key exchange via OOBI. However, in the case of communication between Signify-ts and KERIA, I assumed it might not be the same and that a reverse proxy such as Nginx might be needed to enforce HTTPS.

[kentbull]

I assume that anyone who gains access to that environment could interact with the KERIA Agent.

This is incorrect. KERIA uses the Signify protocol, which means all keys for a Signify-style identifier are at the edge, in memory, which means all event signing by that identifier happens at the edge. The Agent is used only to relay messages, not to sign on behalf of the Signify identifier.

From a security perspective, I believe it would be better to prevent this, which is why I asked the question.

If things were like you suggested then yes, it would be better to prevent this. The security architecture of Signify and KERIA already prevent this by design.

does this also include the aspect of encrypted communication

Not yet, though the ESSR work underway will add this.

My understanding was that communication between Agents is encrypted, even over HTTP, due to key exchange via OOBI.

No, this is not the case. Once ESSR lands then we can support encrypted communications.

[kentbull]

In Hyperledger Aries, which implements DIDComm, the Web Agent provides a REST API, allowing access from an application backend, making access control manageable.

@t-kanuma are you saying that Aries with the Web Agent provides unrestricted access to the agent if you have access to the same physical host? I am as of yet unfamiliar with the Aries architecture, and I also know next to nothing about the DWN node architecture. I would hope that those decentralized identity architectures rely on edge keys for signing requests for authentication and authorization rather than providing open access through a REST API. KERIA and Signify do not provide such open access. A KERIA Agent is merely a communication proxy, like a mailbox (store and forward agent) that is used to coordinate communications. The agent is not issued any credentials or used in any way other than as a persistent online presence that the edge Signify key can send signed messages to and receive messages from the KERIA agent.

[t-kanuma]

@kentbull

Not yet, though the ESSR work underway will add this.
No, this is not the case. Once ESSR lands then we can support encrypted communications.

This is very helpful information. Thank you so much.

[kentbull]

To be clear, the KERI, ACDC, CESR, and TSP protocol stacks already support ESSR and there are already community members using ESSR for confidentiality. What I was referring to is that full ESSR support for communications between SignifyTS and KERIA has not yet been completed and is partially underway.

[t-kanuma]

@kentbull

In Aries, Cloud Agents are provided for organizational roles such as Issuers and Verifiers. (I previously referred to them as Web Agents, but that was not the best expression.) These Cloud Agents handle processes such as signing and verification according to the Aries Protocol on the backend. The backend of a web application calls the APIs exposed by these agents. Authentication for these API calls can be managed using options such as API keys. Additionally, Cloud Agents support multi-tenancy.

Aries also has Edge Agents designed for individuals to use as Holders in applications on mobile devices. These Edge Agents handle all processing on the front end and store data locally. Since they do not have a global IP (endpoint), a Mediator is deployed on the backend. The Mediator, similar to email relays, is shared among multiple Holders to route peer-to-peer messages.

DWN (Decentralized Web Node) is similar to Aries' Edge Agent in that it operates applications on the front end to handle signing, verification, and business logic. In DWN, data is stored on the front end, but a copy is also synchronized with backend nodes. This setup allows other entities to retrieve or send data to a specific individual by querying an endpoint. Additionally, DWN backend nodes are multi-tenant, meaning a single host can support multiple front-end entities.

[t-kanuma]

I understand the concepts of KATE and End Verifiable, and my question was based on that premise. However, I realize that the quality of my question was not optimal, and I was not able to convey my intention effectively. That said, through the process of asking the question, I was able to clarify some points for myself. Therefore, I would like to close this question. Thank you for your help.

[kentbull]

The backend of a web application calls the APIs exposed by these agents. Authentication for these API calls can be managed using options such as API keys.

This is fascinating. This means that Aries agents use bearer tokens to authenticate to their agents. I did not know that. KERI and ACDC were designed to avoid using things like bearer tokens. An API key is a kind of bearer token.

Bearer tokens are vulnerable to a number of attacks that KERI is not vulnerable to at all because KERI uses a no-shared secrets architecture.