Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No addRootKeyId functionality #42

Open
louismorgan-linaro opened this issue Dec 7, 2023 · 13 comments
Open

No addRootKeyId functionality #42

louismorgan-linaro opened this issue Dec 7, 2023 · 13 comments

Comments

@louismorgan-linaro
Copy link
Contributor

I notice in the Python library, there is a set_root_key_id method on the builder construct, but nothing like that seems to exist in this library.

Are there plans to add it? Or is it equivalent to just add the root key id as a normal fact?

@divarvel
Copy link
Collaborator

divarvel commented Dec 7, 2023

It has not been exposed yet. That could be a nice first contribution.

The difference with python is that we can't move JS closures to the rust side, so we can't have a key selection based on the root key id function in JS (we might be able to work around it by providing a map instead of a function to provide minimal support).

If you're interested i can provide guidance / help.

@louismorgan-linaro
Copy link
Contributor Author

I am interested, although it's probably something I would have to do in my spare time. I've limited experience with WASM, so a good place to start would be guidance on that.

For clarity, if I were to set a fact when creating the biscuit like root_key_id=1234; would biscuit consumers in other languages, e.g. python or rust be able to provide a function to select a key the usual way? Or does the root key id need to be set in a special way, hence the dedicated method?

@divarvel
Copy link
Collaborator

divarvel commented Dec 7, 2023

The key id is set in a different way indeed: since it is needed to verify the token signature, it is used before any datalog operation happens, so it requires being set this way. The setting part is easy to do. The trickier part is using this key id when parsing a token in biscuit-wasm (which might not be an issue for you if you intend to use this lib only to mint tokens (or to only consume tokens signed with a single key).

As for the wasm setup, it's fairly well integrated in cargo.

  • you need to install wasm-pack (cargo install wasm-pack) and npm + node
  • then you can run npm run prepare-package (will compile the rust code to wasm, compress the output, generate the JS support code)
  • then you can cd to examples/node and run npm run start

When exposing a new function like setRootKeyId, most of the work is defining a new function in the rust code, with the proper annotation for exposing it as a JS function, and add a couple JS tests to make sure it behaves as expected.

@louismorgan-linaro
Copy link
Contributor Author

Thanks very much for all the info. As you've correctly deduced, my main interest is in minting tokens although it would be nice if our front end could also perform the key selection natively.

I will certainly attempt to implement the setRootKeyId function, and depending on how that goes I will ask for more help and try to implement the key selection piece.

@louisjmorgan
Copy link

Thanks for merging the commit relating to setRootKeyId, do you have a timeline for when the next version of this package would be published to the npm registry?

I would also be keen to have a look at the key selection part. I guess your idea to use a map instead of a function would be something like:

  • a wasm binding in rust that takes a javascript object as the argument.
  • inside the rust function it creates a key selection function based on that object.
  • The javascript object would be like:
{
  [key id]: {public key}
}
  • the key selection function logic would just look up the key id in that object and return the public key if it finds a match.

Is that more or less right?

Based on reading the wasm serde bindgen docs, it seems like using a json string as the argument could be faster than a js object as well?

@pcolmer
Copy link

pcolmer commented Jun 27, 2024

@divarvel Are you able to give any indication when there might be a new release of the wasm package that includes #44 ?

@divarvel
Copy link
Collaborator

@divarvel Are you able to give any indication when there might be a new release of the wasm package that includes #44 ?

I'm planning a release next week

@divarvel
Copy link
Collaborator

divarvel commented Jul 1, 2024

#47

@louisjmorgan
Copy link

@divarvel thanks! Is anything additional required to publish the new version to npm?

@divarvel
Copy link
Collaborator

divarvel commented Jul 1, 2024

@divarvel thanks! Is anything additional required to publish the new version to npm?

nope, https://www.npmjs.com/package/@biscuit-auth/biscuit-wasm/v/0.4.1

(i gave adding key selection a try, but it's a bit more involved, i don't have anything working yet)

@louisjmorgan
Copy link

(i gave adding key selection a try, but it's a bit more involved, i don't have anything working yet)

I'm happy to have a go if you don't have time

@divarvel
Copy link
Collaborator

divarvel commented Jul 1, 2024

(i gave adding key selection a try, but it's a bit more involved, i don't have anything working yet)

I'm happy to have a go if you don't have time

i pushed a branch with the current state of things https://github.com/biscuit-auth/biscuit-wasm/tree/key-selector

part of the changes are due to an update to crypto.
For now it fails at the JS / WASM boundary. Public keys are objects that live within the wasm space, and JS just manipulates pointers to it. I haven't found a way to pass map of pointers. One solution if nothing else works would be to pass a JSON object, with stringified key ids as keys and keys as string values, but that's a bit of a hack.

@louisjmorgan
Copy link

Thanks, I will take a look this weekend if you haven't solved it by then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants