Sandbox options in 2.4.0

Questions
1

Hello, i am working on DAML upgrade from 1.16.0 to 2.4.0 and my old daml.yaml looks like this:

sdk-version: 1.16.0
name: xyz
source: daml
parties:
  - Party1
  - Party2
version: 1.0.0
init-script: Setup:setup
sandbox-options:
 - --ledgerid=xyz
 - --w
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script

Now i see that in 2.4.0, --ledgerId and --w is not supported thanks to this article. What i wan’t to know is that how does commenting out sandbox-options affect my project as it is in production already and has a lot of data on DAML. I see that DAML starts by default in static time mode and not in wall clock mode, is there a new way to tell DAML to start in wall clock time mode?

Also, the ledgerId seems to be picked up from participantId, hence is there a way to set participantId in the daml.yaml file?

2

Hi @nagendra,

Wall clock mode is the default so you can safely omit that. As for the ledger ID, that field has been deprecated in Daml 2.0 and you can omit it from requests. So rather than trying to change it, I would just use the default one and ignore it wherever you currently rely on it.

3

Hi @cocreature,

I tried to hit /query JSON API without ledgerId in the JWT, i get below error. Am i missing something?

{
    "errors": [
        "ledgerId missing in access token"
    ],
    "status": 401
}

i have started daml without ledgerId, also seems like ledgerId is defaulting to “sandbox” as i get below error when i send ledgerId as xyz

{
    "result": [],
    "errors": [
        "Endpoints.ParticipantServerError: NOT_FOUND: LEDGER_ID_MISMATCH(11,0): Ledger ID 'xyz' not found. Actual Ledger ID is 'sandbox'."
    ],
    "status": 501
}
4

You need to use one of the new user tokens instead of the old custom scope tokens. Take a look at Authorization — Daml SDK 2.5.0 documentation.

5

Yes, i am trying new access token formats, but still see same issue.

First format:

{
  "aud": "com:org:xyz",
  "iat": 1672924351,
  "exp": 1672927951,
  "nbf": 1672924351,
  "sub": "user@user.com",
  "https://daml.com/ledger-api": {
    "actAs": [
      "Party1"
    ],
    "role": [
      "abc"
    ],
    "admin": true,
    "applicationId": "efg"
  }
}

second format[since the documentation suggests we can bring out the nested attributes to same level as exp]:

{
  "aud": "com:org:xyz",
  "iat": 1672918005,
  "exp": 1672921605,
  "auth_time": 1672918000,
  "sub": "user@user.com",
  "actAs": [
    "Party1"
  ],
  "role": [
    "abc"
  ],
  "admin": true,
  "applicationId": "efg",
  "party": "Party1",
  "group": "Group1"
}
6

That’s still the old format, the whole section under https://daml.com/ledger-api should go away.

7

Ok, i will try the below format and see if it works.

{
   "aud": "someParticipantId",
   "sub": "someUserId",
   "exp": 1300819380,
   "scope": "daml_ledger_api"
}
8

One query on the below format though.

{
   "aud": "someParticipantId",
   "sub": "someUserId",
   "exp": 1300819380,
   "scope": "daml_ledger_api"
}

We use okta for authentication which gives the JWT we pass on to DAML JSON APIs. We have few scopes defined on okta, for example ledger, migration, user etc. How does DAML derive actAs, role, party etc properties from the given scope?

9

The actAs and readAs rights are derived from the rights you’ve given to the user as specified in sub Take a look at the docs for user management for more details.

10

Ok, this requires users to be stored on DAML. The thing is our users are stored on OKTA and authenticated on OKTA, only user’s contracts are stored on DAML, so we cannot use audience and scope based tokens in our project[at least at this point of time]. Any suggestions on ledgerId now? Will it default to sandbox always so that i can use the same in my access token?

11

If you go through daml sandbox then yes it should always be sandbox. As mentioned in the docs sandbox is a wrapper around Canton that configures one in-memory participant called sandbox.

Keep in mind though that Sandbox i(as the name suggests) is not a production ledger. For that you want to run Canton directly. As part of that you can then chose the participant name which maps to the ledger ID.

I do recommend putting in the effort to migrate to user management though. It can simplify things a fair bit in most cases.

12

You are right, we are thinking of migrating to user management to make things simpler. Thanks a lot for your inputs.