-
Notifications
You must be signed in to change notification settings - Fork 75
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
Extension Signing request endpoint #982
Conversation
...h/pegasys/web3signer/core/service/http/handlers/signing/GenericSignForIdentifierHandler.java
Outdated
Show resolved
Hide resolved
...h/pegasys/web3signer/core/service/http/handlers/signing/GenericSignForIdentifierHandler.java
Outdated
Show resolved
Hide resolved
...h/pegasys/web3signer/core/service/http/handlers/signing/GenericSignForIdentifierHandler.java
Outdated
Show resolved
Hide resolved
core/src/main/java/tech/pegasys/web3signer/core/config/BaseConfig.java
Outdated
Show resolved
Hide resolved
acceptance-tests/src/test/java/tech/pegasys/web3signer/dsl/signer/Signer.java
Outdated
Show resolved
Hide resolved
@JsonProperty(value = "platform", required = true) String platform, | ||
@JsonProperty(value = "timestamp", required = true) String timestamp, | ||
@JsonProperty(value = "pubkey", required = true) String pubkey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These look like specific properties for a PROOF_OF_VALIDATION
type rather than a generic signing type. Perhaps just rename SigningExtensionBody
to ProofOfValidationBody
?
} | ||
|
||
private static String headerBase64() { | ||
return BaseEncoding.base64().encode("{\"alg\": \"BLS\", \"typ\": \"BLS_SIG\"}".getBytes(UTF_8)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this need a header? This is done differently from how we sign everything else.
routingContext.response().putHeader("Content-Type", JSON_UTF_8); | ||
routingContext | ||
.response() | ||
.end(new JsonObject().put("data", dataToSign).put("signature", blsSigBase64).encode()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to include the original data, the sender already hash that. And this change response format to being specific for extension signing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we now in terms of API docs for this?
I'm thinking it will be hard for a future user to understand how to use this API, e.g. what should they put for "platform"? Also, wondering if platform is strictly necessary in the request?
@@ -2,6 +2,9 @@ | |||
|
|||
## Next Version | |||
|
|||
### Features Added | |||
- Added endpoint `/api/v1/eth2/ext/sign/:identifier` which is enabled using cli option `--Xsigning-ext-enabled=true`. This endpoint allows signing of additional data not covered by the remoting API specs. [#982](https://github.com/Consensys/web3signer/pull/982) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if we should put this under a web3signer-specific namespace? e.g. /w3s/v1/eth2/sign
, /w3s/v1/sign
or/v1/eth2/w3s/sign
.
There's precedent in teku for spec vs teku-specific https://consensys.github.io/teku/#tag/Teku and I think there's some merit for web3signer to follow that pattern.
Other CLs too: https://lighthouse-book.sigmaprime.io/api-lighthouse.html
@@ -13,6 +13,7 @@ | |||
package tech.pegasys.web3signer.core.service.http; | |||
|
|||
/** Operation IDs as defined in web3signer.yaml */ | |||
@Deprecated(forRemoval = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this class was used when we had vertx "openapi router". We have since removed that router and this interface is unused.
public record ProofOfValidationBody( | ||
@JsonProperty(value = "type", required = true) SigningExtensionType type, | ||
@JsonProperty(value = "platform", required = true) String platform, | ||
@JsonProperty(value = "timestamp", required = true) String timestamp) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be timestamp typed? Makes sense to me to be the same as other timestamps, i.e. UInt64
Not sure platform should be types...what is platform actually used for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking to use uint64 as well because that would allow numerical literals both quoted and unquoted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
Uses custom copy of global ObjectMapper with FAIL_ON_UNKNOWN_PROPERTIES enabled
...java/tech/pegasys/web3signer/core/service/http/handlers/signing/SigningExtensionHandler.java
Show resolved
Hide resolved
-- Disable IPv6 in docker container for goss_wait test
PR Description
An extension sign endpoint
/api/v1/eth2/ext/sign/:identifier
which can be enabled with cli option--Xsigning-ext-enabled=true
The cli option is associated witheth2
subcommand. For example./web3signer eth2 --Xsigning-ext-enabled=true ...
. This extension covers some additional signing types and use-cases which are not covered by the remoting API specs and hence should be used at your own risk.The format of request payload is:
Only
PROOF_OF_VALIDATION
extension type is supported at the moment. Any other type would result in an error.The signature is hex encoded string calculated as:
signature = BLS.sign(payload.getBytes()).asHexString()
For default accept type (
*/*
) andJSON
accept type headers, the response is in following format:Note:
Payload is returned in the response as Base64 encoded String.
Signature is returned as Hex encoded String
This would allow the users of this endpoint to verify the payload is signed by appropriate private key.
Fixed Issue(s)
Fixes #976
Documentation
doc-change-required
label to this PR if updates are required.Changelog
Testing