Proposal: a Ledger API Proxy run on top of Canton Ledger API to provide authentication and audit trail (RFP 25, Identity and Access Control and RFP 27, Security Monitoring, Auditability and Evidence)

This adds operational complexity by having teams needing to deploy, maintain and operate another DB technology rather than utilise PostgresQL which will already be deployed and required.

This is generally a poor SecOps practice for the reasons stated but aware that this happens.

Specifically for node keys but not for external signing.

I wonder how much of this should be implemented directly within the Ledger API / Canton runtime. However this is functionally similar to a WAF gateway on front of Ledger API.

Some of the comments below suggest some form of persisted data within the proxy - for example daily trading volumes as a basis for policy. Does this persist state to DB (separate from policy rules and logging)?

On the basis that a compromise of the gateway would result in a uncontrolled access, a security audit of the proxy is important. This is no different the Ledger APi itself.

How have you thought about performance of the gateway and will you perform any performance / throughput testing?

How are you thinking about key storage. I'm assuming these are used to signed the JWTs to the Ledger API and thus critical if proxy is compromised

Hi @nycnewman

That's one of the thing I'm going back n forth a lot before we settle on DuckDB for our internal use. It's an embedded db so there is no extra thing to provision rather than giving it a volume. So from user perspective, they don't have to setup another database.

Usually, a SQLite will work here as well, but we choose DuckDB beause:

• the columnar storage format and compression allow it store and query audit log efficiently. Log storage typically queries throug bulk aggreagration. We rarely want random primary look up
• Native compression
• Native Parquet support allow us to dump the file to parquet and query them right away

To avoid storage go out of bound, a pruning and export feature is provided.

From my experience to support the validator, many has actually not paying much attention to their Postgres DB and actually not having much experience dealing with PostgresDB.

I'm afraid that adding a PostgresDB will actually increase the complexity of handling log volume with Postgres, hence DuckDB was chosen.

I hope to make this service a drop-in replacement where user can just run it and don't need to worry about another database they need to manage.

While it's a new technologies, end-user won't deal with it directly. And the user who want to deal with it directly is likely very familar with Parquet format.

Yes, indeed. Before, I run NaaS and one of requirement was to install app like SyncInsight which need ledger access. Some just get the habit of copying client id /secret to share.

I had updated to clarify this is node key and not applied to external signing

Yes, all state will be persisted to the embedded db. There is a WAL buffer to handle the crash.

There is a batch insert loop that run and flush to DuckDB every 10 seconds to batch insert log, example. ACS query are the endpoint get hit the most now.

I will update the docs to clarify this more.

Edit: proposal is updated to add information that both of audit log and quota data is stored inside DuckDB.

Yes, I will add a new milestone to get an audit for this.

Edit: a M4 milestone to engages with an independent vendor to perform an audit.

Yes, we had perform a simple load test with a mock ledger internally (essentially just a dummy json server). I will update the proposal to add information about load test including methodlogy and the result.

our current load test is done through running vegata against the gateway run on top of a mock ledger.

Edit: I add point 12) about providing benchmark and load test

Yes, there are 2 concept of keys here

1. Key that LedgerShield returns to end-user: This is actually an opaque key. This key is simply use for client to authenticate to LedgerShield. LedgerShield doesn't store this key. It just store the hash of the key. And the key is only show once up at creation. If client lost it, they need to create another key, and attach the desired policies.

When I mention about key rotation is the idea of provisioning a separate key and switch over(so there are period both keys are valid) and then an operator manually revoke the old key.

2. The OIDC key(client id / secret) of the machine to machine app

This is currently store in environment variable. And this follow exact same format of docker compose or helm deployment.

The idea is that deployment of this service will be very similar to a normal validator, such as in docker compose it will be https://github.com/canton-network/splice/blob/main/cluster/compose/validator/compose.yaml#L90-L91

So in term of storage, LedgerShield only store the hash of the key in its db, and perform a constant time look up when the request come in, and evaluate against the policies.

I think at minimum, simply to have authentication at endpoint/method level is already help. To prevent privileges esclation, and lock down a party to a certain endpoint.

However, even if we did so, the permission is still at the party level. To bring in the concept of key that is tied to party, but can have different permission, will require I think a bit of work across the stack to pass some kind of additional information.

So I suppose currently it makes more sense to develop this separately for the time being.

Maybe we need to be careful with terms. I thnk of "key" as a cryptographic key, i.e. public or private keys. Whereas I think for the client you mean a "bearer token" (opaque data that is pass in call header)

ah, that's an excellent point. Let me update the PR as well.

Edit: I updated the proposal to start to use the bearer token term to avoid any confusion

It is not clear to me how is this token issued. How does the client application get hold of that token? How is it refreshed?

Are you saying that the tokens will be valid for 30 days?

What about the long lived web-socket streams that have been open on a now revoked key? In theory they can go on for weeks.

Hi @mziolekda

That API bearer token is an opaque token, manage by Ledger Shield itself. It's control by a policies on what it can do. There is no refresh process because it isn't a OIDC token. It is a concern between the client <-> LedgerShield only. As long as they key is valid(not revoke), and the policies of that key allow it access, LedgerShield use client id/secret to create the JWT access token, and hit ledger and return to end-user.

The process of provision this token it one time in the LedgerShield admin ui, or through LedgerShield admin api. This token is traditional API token, not the access token in term of OIDC app.

When an operator want to onboard a new app, let say they want to create a read-only API token so an app can index, they can create a API token as the above screen.

Below, is a policy for a read-only app, it can only query ACS/Ledger end.

It was an example I tried to illustrate the scenario where we want to give access for testing external app that need ledger api.

This API token is opaque and its TTL is defined at creation by the operator.

Say Alice and Bob are testing 2 different accounting software, they can create this and give it to the accounting software. Traditionally Alice and Bob will have to create 2 different OIDC app (or re-used a single OIDC app), bind it to a party through {party_id, name} , and then grant readAsAny to that party so they can fetch v2/updates.

These API token are scope to Ledger shield itself, not the OIDC token.

LedgerShield will terminate the connection in the next message of websocket stream when an API key is revoked.

Today the API key is revoked by either: an operator revoke it, or the API key past its expiration time.

It is multiplexing the request and not just pass through. So for example today, without ledger shield a consumer does this

wscat -w -1 --connect 'wss://ledger-api.devnet.upflam.com/api/json-api/v2/updates' -s 'jwt.token.<access-token-return-from-oidc>' -s 'daml.ws.auth'

With ledger shield it will now become

wscat -w -1 --connect 'wss://shield-api.devnet.upflam.com/api/json-api/v2/updates' -s 'jwt.token.<api-token>' -s 'daml.ws.auth'

Then ledger shield will checking the permission of that api-token, getting an JWT token(it hold client id /secret), connect to ledger, read/retreive message and return to consumer. It check the API key the next time it call connection.Read(ctx).

The way we currently implement is:

• At boot, the app load all active API key. And inititiate a sync thread to sync the database(add/revoke)
• Anytime we process a request, it check the API key permission and liveness. We can do that because it doesnt hit any database(the database syncing is on a different thread).

Getting auditors' approval on long lived tokens is going to be challenging IMHO.

Typically a TTL of around 5min is considered acceptable. Your solution does not have provisions for refreshing the tokens frequently which leaves it exposed to a whole host of attacks.

I second what @nycnewman has said. This solution is replacing both the IDP and Ledger API Auth Layer. The attack surface is larger than the LAPI itself. This will require a very thorough external audit.

Isn't it the same as the app has client id/secret?

Today, app in Canton usually operate by having the credential of client id / secret of the m2m app in the env. Then the app will use it to exchange for short live access token. The app is holding the long live secret key of OIDC auth(auth0, keycloak). This OIDC client secret is usually has a quite long lifecycle, because rotate it require coordination with validator, participant and any other app that use these such as the utility.

On the deployment of dar syncer it is using client secret https://docs.digitalasset.com/legacy-docs/legacy-docs/setup/install-docker-compose And this client secret is fundamentally the operator party.

With this API key concept, we can create API key that is only able to upload dar, which is even more secure IMHO.

And the API key all has a TTL key, also IP bind, and it's up to the operator of the app to choose and configure their frequency of rotation such as 30 days if they choose so.

So I don't think it's less secure or have any different issue. Apps don't store the JWT access token in the env, they store the long live OIDC credential. We now skip setting that in env var, the developer set this API key in their docker compose/k8s secret instead of the OIDC secret.

Yes, I had added M4 milestone to engages with an independent vendor for external audit. Does DA have any recommendation for such an auditor?

Interesting proposal. Scoped access and auditability are relevant areas for us at Fairmint. Glad to see open-source tooling exploring this—we’re interested in following its progress.

Thanks for putting together this proposal. I think this would be generally useful for my team.

I think we can try deploying and testing it

I think the proposal should also call out CIP-103, which specifies (among other things) a standard for gateways in front of the Ledger API. I believe most implementations of this standard use a similar setup as described here, where the gateway adds authentication and internally uses a user with broader rights.

The scope is somewhat different since CIP-103 specifies a TypeScript API, and this proposes an application-level network proxy. But at the very least, I think the proposal should call out the differences and advantages of having this as a separate layer. But it could be interesting if the Rego policies were usable by wallet providers without too much extra effort.

Oh, that's a good point. I did consider it but wallet gateway was built for wallet integration API.

Where as here we aim for an API that is 100% compatible with LAPI in term of API surface including request and response with some ACL.

Let me update the docs to call out the prior art and the difference

From a validator/operator perspective, this would be a very useful addition. Better access control and audit logs around the Ledger API would make day-to-day operations much easier to manage, especially as more services start connecting to the same validator setup.

Would definitely like to see this move forward! :)

Interesting proposal. Scoped access and auditability are relevant areas for us at EA Finance & EQ Market. Glad to see open-source tooling exploring this—we're interested in following its progress.

Thank very much for your review @jaspervdj-da I had added the docs about comparison with wallet gateway. https://github.com/canton-foundation/canton-dev-fund/pull/788/changes#diff-b9f233c035679590c1770554234c54fd7b0385d575f3f9379737259edcfd6b77R275

Looking forward to your feedback.

why is it better to implement IP whitelisting at the verification stage instead of at the IdP during token issuance? does this not go against the definition of a bearer token (as per https://www.rfc-editor.org/info/rfc6750/)? if IP whitelisting is really needed, why not offload it to a separate network firewall, why must it be bound to the token? also could this not introduce fragilities for users using dynamic VPNs, load balancers, proxies, various cloud runners?

the same would apply to the holders of LedgerShield’s credential, right? also, since the parties trusting the participant node operator/admin is an inbuilt trust assumption for single-node parties (without external signing), the participant admin granting themselves party rights shouldn't be a primary concern. To ensure that trust doesn't concentrate in one participant, multi-hosting or external signing can be used

do i understand correctly that the primary underlying issue here is the use of machine-to-machine credentials (here, OIDC client ID and secret) by human developers in practice (instead of dedicated per-user identifiable human credentials)? (combined with the fact that finer-grained scopes are not available)? What about solutions such as mTLS (supported by the ledger API) or mTLS with token binding (https://www.rfc-editor.org/info/rfc8705/)? or simply storing the client secret in an HSM, etc.?

i don't quite see why this is called a workaround? it seems to be the standard/intended use of OIDC based on the standard (https://www.rfc-editor.org/info/rfc6749/)

I see multiple security-relevant issues here:

1. Attack surface clearly increases drastically from per-app client OIDC secrets and short-lived JWTs to multiple potentially powerful long-lived bearer tokens per party + one all-powerful client secret belonging to LedgerShield that has the potential to compromise every party at once.

2. Bearer tokens are vulnerable to interception (e.g., via logs, network traces, or cache leakage), which is why standard OAuth frameworks enforce very short TTLs (usually 5-15 minutes) to automatically close the replay window. Implementing these long-lived tokens is highly non-standard.

3. A single per-app client secret used to get access tokens can easily be stored in an HSM and protected from misuse (or can be replaced with mTLS binding, etc.), for multiple long-lived bearer tokens that are used per request, that too for all the parties on the node, protecting them becomes infinitely more difficult.

4. The responsibility and risk of managing application secrets is being transferred from the app builders and IdPs to the node operators for no clear benefit or reason other than the fact that the application builders are seen to not follow security best practices for secret management. If the client secret of LedgerShield is compromised, every party gets compromised and can legitimately blame the node operator. I don't see why a node operator should take on the sole responsibility for credential management.

it's up to the operator of the app to choose and configure their frequency of rotation such as 30 days if they choose so.

Unless I misunderstood, the rotation process for the long lived keys seems to be manual? This means the application's security is entirely at the mercy of the operator remembering to rotate keys on time, which goes against most security guidelines (e.g. see https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html).

If one of the main premises is that app operators do not use credentials correctly, how can we trust them with regular rotations? As before, they would just again go with the most convenience-aligned approach and issue very long-lived tokens

As a general high-level comment, I am quite concerned about re-implementing the full functionality of an IdP / API Gateway, especially if using this security implementation that is incompatible with the OAuth 2.0/OIDC specifications, which have been developed over years and been exposed thoroughly to multiple theoretical and real attack scenarios.

NIST SP 800-63 (Digital Identity Guidelines) lays out extensive requirements for authenticator lifecycles, secret storage, and token issuance. How does this proposed implementation plan to satisfy such security assessments and compliance audits (e.g., SOC 2, ISO 27001)?

why is it better to implement IP whitelisting at the verification stage instead of at the IdP during token issuance?

Because we can fine tune that this IP address belong to this bearer token. Example, I can say this should only being used under vendor A ip-range.

does this not go against the definition of a bearer token

No, this is not parter of the bearer token of OAUTH2 framework. In this, we're issueing opaque token, that is back by our policy.

if IP whitelisting is really needed, why not offload it to a separate network firewall, why must it be bound to the token?

I think highly sensitive operator all already use network firewall for ledger api or auth proxy already. But they aren't able to say that this token should only being used under vendor A Ip range, instead all the ip range are whitelist and that's it.

Example, if we connect a vendor to ledger for accounting purpose, now we need to whitelist that vendor IP. We cannot say "This token I give to this vendor" should not be used in other "vendor".

I'm very comfortable knowing that once I shared this token to vendor A, I will get an alert if it's being used outside of vendor A iprange.

Usecase 1: Lets say we want an api bearer token that can only upload and vet DAR file. We want this token to only being used under CI/CD ip range(github runner, self-hosted)

Usecase 2: I'm connecting with an explorer app from third party to index ledger data in a read-only manner(v2/updates, ledger end only) etc.

Cloudflare has this feature for example, when generating an API tokens, we can optionally define Client IP filtering.

also could this not introduce fragilities for users using dynamic VPNs, load balancers, proxies, various cloud runners?

This is egress IP. It's exactly as today validator has to submit egress ip to be whitelist on sv. VPNs is actually compliment this. An engineer can use their company corporate IP or their VPN exit node IP to lock down their access.

Also, this is an option flag user who desire this level of security configure on that token.

the same would apply to the holders of LedgerShield’s credential, right?

That's exact reason why we built this. The point is that LedgerShield can issue very fine tune API key, so we don't have to issue party admin privielegs token.

Example, more often than not I found the credential of M2M app(client id/secret) was given to contractor, because they need to configure DAR, setting right and provision users etc.

When I was running node for other, the node owner wasn't even aware of the dangerous of sharing client id/secret.

the participant admin granting themselves party rights shouldn't be a primary concern

The concern is not about not having fine tune permission that contains less privileges than party_admin. Pretty much, the moment we give someone party admin it's end game there. it's like giving a user without root, but add them to docker group, and now they can have root.

Today, we cannot break down privileges of participant admin.

The point of this is we can define granularity permisison and api key, and avoid giving token that has more scope that it needs.

do i understand correctly that the primary underlying issue here is the use of machine-to-machine credentials (here, OIDC client ID and secret) by human developers

Yes, that's correct. It's one of the concern though. It isn't the main concern. The main concern is today, we cannot fine tune much.

I really wish to be able to say. Lets this user be able to upload, create their own contract, fail v2/updates etc but don't let them transfer the asset out for example.

Before I was a NaaS for others and we were asked to provision these kind of config. Example dfns https://dfns.co/article/canton-byov-support It's dangerous without ability to fine tune them.

(instead of dedicated per-user identifiable human credentials)?

In practice though, it's quite cumbersome. There are a reason eventually people share the client id/secret of the m2m app.

Even with per-user identifiable that is typically mean allocating party, bind the sub field to that party. Then sooner or later we eventually want this user to be able to actAs someother user to query acs for debugging purpose example, and to submit some kind of Daml tx, such as creating contract. But we want to prohibit them from exercising a certain choice.

It's a whole dance to get that right, and even so, the tooling today is limited.

combined with the fact that finer-grained scopes are not available

Yes, this is indeed the primary concern.

What about solutions such as mTLS (supported by the ledger API) or mTLS with token binding (https://www.rfc-editor.org/info/rfc8705/)

That doesn't solve the 2 pain points I mention above. And today, I think majority of app is deploy with OIDC(auth2, keycloak being the most common)

or simply storing the client secret in an HSM, etc.?

I'm unsure how this will help. Very commonly we will want to access the raw token, put it into app like Bruno, PostMan etc. Or when we share the token with a third party vendor, it's up to them on how they secure it. And for us, we want to fine tune and follow the least privileges access.

It is a workaround because you cannot define or create a token with limited privileges to the same party, lead you have to do this in 2 places:

1. create a OIDC app
2. create a new party and link to it . configure this party through read as, act as etc

User, at least for me, I would like to use a token scope to a party, fine tune permission.

I am quite concerned about re-implementing the full functionality of an IdP / API Gateway, especially if using this security implementation that is incompatible with the OAuth 2.0/OIDC specifications, which have been developed over years and been exposed thoroughly to multiple theoretical and real attack scenarios.

I don't think such we are re-implementing this because there is not such a system existed today. We cannot perform what we want to achieve, from an operational standpoint, follow least privileges practice.

We are indeed complementing it, the LedgerShield still hold a broader OIDC. We do not replace, we built on top of it.

This kind of concept has been implement by Digital Asset in this project too: https://github.com/canton-network/wallet/tree/main/wallet-gateway/remote where an app hold a more powerful token, you can see the similar concept here of https://github.com/canton-network/wallet/blob/main/wallet-gateway/remote/src/middleware/apiKeyAuth.ts#L55-L61 where we're hashing an opaque token and store in a table https://github.com/canton-network/wallet/blob/c645d33a29e87b5d87b969f6fee5fef7b6f1139f/core/wallet-store-sql/src/migrations/013-add-api-key.ts

The fact that user doesn't deal with OAuth2.0/OIDC doesn't mean we're re-implementing it.

For API Gateway, is there a system that can support the requirement listed in the proposal today? I supposed one can implement some WAF here to inspect the content of request and reject it with quite a bit of be-spoke rule to handle these. And if everyone have to write a ton of WAF rule, why don't we standarize this with a software build specific for Canton.

NIST SP 800-63 (Digital Identity Guidelines) lays out extensive requirements for authenticator lifecycles, secret storage, and token issuance. How does this proposed implementation plan to satisfy such security assessments and compliance audits (e.g., SOC 2, ISO 27001)?

No, A long-lived API bearer token is a long-term authentication credential, just like an OAuth client secret. They are following the same practice of storing such token. NIST's guidance does not establish that long-lived bearer credentials are categorically prohibited. The security properties depend on scope, privilege, storage, rotation, revocation, auditability, and the consequences of compromise.

Upflam is a spin off of https://getopty.com/, and have done client work to perform SOC2 audit before and very familiar with these framework.

We're indeed complimentary and fit nicely with NIST. Because we allow to fine tune very detail permission and time based, ip bind, scope them down, add audit log to all API key activities.

that is incompatible with the OAuth 2.0/OIDC specifications,

We do not replace this flow of Ledger API. It's an optional layer, it doesn't change the API of ledger. And using it is 100% compatible with the current workflow, don't even require changing code or their exissting API request.

Lets walk through the life cycle of an engineer who work with Ledger API today interactively. They are very commonly do the below

• 1. acquire client id / secret. Hit the OIDC auth url -> exchange access token.
• 2. Take that access token -> use it whenever they want to request ledger

The engineer now can go directly to ii) to use it for LedgerShield. It's replace the client id / secret step. And it can be scope to great detail that policy allow.

It's implement and proposed as an additional system, it doesn't replace or change anything on the existing Ledger API.

And this API concept is already being used in the wallet gateway project too as I mention above.

Unless I misunderstood, the rotation process for the long lived keys seems to be manual? This means the application's security is entirely at the mercy of the operator remembering to rotate keys on time, which goes against most security guidelines (e.g. see

How does this different with today the app is storing client secret credential in the environment env var? and the client secret rotation is entirely manual too. Let take a look at deployment of Helm where client id /secret are store in K8S secret. https://docs.canton.network/global-synchronizer/deployment/validator-kubernetes#configuring-authentication-on-your-validator Our keys here has

OAUTH2 short live token make sense for SPA app. Here, we're only focus on service account usecase(machine to machine). And rotation key here is exactly the same workflow with rotation client secret of the M2M app.

If one of the main premises is that app operators do not use credentials correctly, how can we trust them with regular rotations? As before, they would just again go with the most convenience-aligned approach and issue very long-lived tokens

We should not blame user. That's the wrong mindset. We make something dead easy, through that we encourage best practice. To encourage easiness, we make something easy so it's hard to go wrong.

Rotating secret of M2M app today is not simpler, it would even cause downtime to the app(there is period where the old secret is invalid until app reboot or reload new key). Where as, using this LedgerShield layer we can now even rotate without downtime because a new API key attach to the same policies can be issued. So there are new API key can be issues.

And not just that these API key can have expiration time, not like client secret which doesn't have. At least auth0 or keycloak has not such concept.

And not just time based, these token are also locked per IP. Depend on sensitivty of credential it can have different policies.

1. Attack surface clearly increases drastically from per-app client OIDC secrets and short-lived JWTs to multiple potentially powerful long-lived bearer tokens per party + one all-powerful client secret belonging to LedgerShield that has the potential to compromise every party at once.

No, the attack surface is actually reduce, not increasing at all.

1. per app client id/secret + short-live JWT

Notice that client secret is there, JWT is short live but client secret is not. Shortlive jwt make sense for SPA, For client secret tho, to be consumed in machine to machine manner, then it's inherit the same attack surface with the long live api key. Client secret. has the same storage semantic with our API key here

2. one all-powerful client secret belonging to LedgerShield that has the potential to compromise every party at once.

This is no different from client secret belonging to the app today, right? Majority app is already in such case, and already hold that all-powerful credential.

What we gain is ability to have more fine tune token. Today, the app hold that root credential typically. App who choose to deploy with LedgerShield, move that concern to LedgerShield, and use the API token LedgerShield issue to it.

2. Bearer tokens are vulnerable to interception (e.g., via logs, network traces, or cache leakage), which is why standard OAuth frameworks enforce very short TTLs (usually 5-15 minutes) to automatically close the replay window. Implementing these long-lived tokens is highly non-standard.

Client secret is subject to the exact same thing in this setup. It makes benefit for client side app(SPA), especially in flow where we issue token to third party app.

But in an machine to machine setup, with client secret of M2M, this doesn't reduce any security practice.

And No, I don't think long-lived token is highly non-standard? Example Stripe/Cloudflare/OpenAI/Anthoripic/Github all use opaque API key.

We did not deploy this in a SPA manner. We issue this token in place where we traditionally use m2m token, where it's commonly client secret is used.

All of this token can have auto exipired TTL like 30day/90day and the operator can rotate them. It's infac even more secure than simply storing the client secret

3. A single per-app client secret used to get access tokens can easily be stored in an HSM and protected from misuse (or can be replaced with mTLS binding, etc.), for multiple long-lived bearer tokens that are used per request, that too for all the parties on the node, protecting them becomes infinitely more difficult.

Likewise, this API bearer token can also be stored in an HSM too.

What we are trying to solve is ability to issue fine tune token in term of permisision, and reduce the operational overhead of team that are using multiple OIDC app today.

Let just take this very simple example. Today, an engineer will very likely using client id/secret of the validator m2m token to debug it.

By using LedgerShield, now they can easily fine create token that bind to this particular VPN, allow it to do multiple things, but cannot access the fund under that party.

4. The responsibility and risk of managing application secrets is being transferred from the app builders and IdPs to the node operators for no clear benefit or reason other than the fact that the application builders are seen to not follow security best practices for secret management. If the client secret of LedgerShield is compromised, every party gets compromised and can legitimately blame the node operator. I don't see why a node operator should take on the sole responsibility for credential management.

It's an optional system, we didn't change LAPI API and add risk. We inherit the same security model of protecting the client secret of m2m app.

Users who want to use separate OIDC can continue to do so.

There is big benefit too. I can also query the audit log and see when this token is being used, and query what. Today, such audit log is fragmented across the OIDC, the web server log. I'm unsure how else I can configure this today.

• "Let create a token that allow user to upload/vet DAR files, setup any contract it need but cannot be abuse to mvoe asset, and only accept this token from Github".
• "Let create an api token for this acouting app to use and only allow this token from this accounting app ip range".
• "Who has attempt to created contract from these template"

A node operator doesn't even need to run this software. An app can deploy it today, using the existing client id/secret that the node operator already hand them.

The true attack surface is if the implementation of LedgerShield failed to enforce policies. That's why we will perform extension fuzzing for this app, as a milestone in M2, to prove its robustness.

If the client secret of LedgerShield is compromised, every party gets compromised and can legitimately blame the node operator.

It works exactly same if an app compromised the client secret. Today, that client secret store inside the app env, and even in more place. Moving that to LedgerShield protect the app more, not less.

finer-grained scopes are not available

Worth noting that we (DA) are working on this as part of this dev fund: https://github.com/canton-foundation/canton-dev-fund/issues/364

Where this is specified as:

Acceptance: Automated tests proving the Gateway issues tokens that strictly limit a dApp's access to specifically defined data sets on a validator.

There is no design available yet, but it will likely take the shape of more granular permission groups and/or being able to limit the set of visible contracts, as opposed to a fully programmable API with Rego. We will need to present these restrictions in a dialog in the wallet gateway, so they need to be simple enough to understand for the user.

Hi @jaspervdj-da That makes 100% sense. I think the use case of wallet gateway is for the end-user of a dapp, so it need to be super easy for end-user to make decision. Where as the usecases of LedgerShield is for app developer/operator

My PR already have RFP alignment map and "who is benefit". I added "How adoption is drive" to both of the propolsal file and the PR description.

Let me know if that's enough

Hi @nycnewman @mziolekda @jaspervdj-da @simran-da Thanks so much for taking the time to leave comment and feedback. I'm greatly appreciate them.

I had addressed all of them by either updating the proposal, or by commenting.

Please have another round of review and let me know if there is still something more to address.

I’ve reviewed this and I’m happy to champion it.

The ask seems reasonable to me, and Vinh has a strong track record on the network as an operator and developer. LedgerShield targets a real gap (scoped Ledger API access + audit without another OIDC client per consumer), the design is feasible, and it fits RFP 25 well.

I read the existing DA feedback; Vinh has addressed a lot of it in-thread. Residual security/audit questions are for Core Contributors / Security and Voting.

I’ll move the board card to Ready for Vote.

/vote

@v9n We're a neutral security marketplace already supporting multiple teams on Canton to connect with vetted, external security audit firms. Happy to support here when the time comes to shortlist firms with relevant experience

Hi @v9n, thanks for submitting this. I've discussed this with some of the DA folks who've reviewed it, and we currently don't support the proposal. Sharing some of the internal feedback below. I haven't reviewed it myself, but I can set up a call with the relevant folks if you disagree.

1. The proposal merges the IDP with the Authenticator/Authorizer, and it relies heavily on very long-lived tokens.
2. It introduces several security risks and increases the operational burden it sets out to solve.
3. The main use case is fine-grained access, which is already work in progress.
4. The design sits between a thin proxy that isn't application- or ledger-aware, like a firewall, and a smart proxy like the wallet gateway.

/cancel-vote