Authorization with different ledgers

Questions
1

Reading the documentation I want to confirm my understanding:

  1. The claims (public, admin, canReadAs, canActAs) are generic concepts that are defined in the interface between an AuthService and the Ledger API Server. All ledger implementations have to support these, but the format / encoding can vary.
  2. The Ledger API Server does not contain logic to interpret a token, but will pass it through to the AuthService to confirm the claims required for the action to be taken. So the format / encoding required for a particular ledger is defined by the AuthService implementation.
  3. The way a token is passed to the API is defined by the Ledger API Server (via gRPC), respectively the HTTP JSON API (via Authorization header). So this is again common to all ledger implementations.

My questions:

  • Is the above understanding correct?
  • The DAML-on-SQL implementation uses JWT token encoding. What other token encodings are common?
  • Where can I find information about the token format / encoding for other ledger implementations, like DAML-on-Sawtooth or DAML-on-Fabric?
2 Likes
2

Your understanding is sort of correct. The Auth Service is a Java API, which defines possible claims. The Sandbox JWT format is fairly faithful to that, but there are claims not currently exposed like the wildcard CanActAsAnyParty.

What you say in 2. and 3. is correct.

I don’t know any other 1-1 alternatives to JWT, but you can, of course, pass anything in the Authorization header. I don’t think it would be difficult to write an AuthService which implements Basic Authentication.

Since authentication is participant specific, information about the authentication token format has to be provided by ledger operators. The OSS DAML-on-Sawtooth and DAML-on-Fabric ledgers use a wildcard AuthService, which allows all requests as far as I know.

1 Like