Updates to key accessors and fix proof algorithm type #124
Conversation
This simplifies the code and doesn't do unnecessary recomputation of the revoked ids collection every time a new block is added. Likely, a relying party would only access the collection of revoked ids once to check revocation anyway. This is in line with the rust implemention that also assembles the collection of revoked identifiers on the fly.
These methods are akin to those of the rust implementation.
|
Why removing revocationsIds from unverified? |
This simplifies the code and doesn't do unnecessary recomputation of the revoked ids collection |
|
|
||
| public Option<PublicKey> blockExternalKey(int index) { | ||
| if (index == 0) { | ||
| return authority.getExternalKey(); |
There was a problem hiding this comment.
note: this will always turn None, there is no external signature on the authority block
| ? new Proof.FinalSignature(data.getProof().getFinalSignature().toByteArray()) | ||
| : new Proof.NextSecret( | ||
| KeyPair.generate( | ||
| authority.getKey().getAlgorithm(), |
|
extracting the revocation ids on the fly is fine, yes. @preuss-adam could you fill the Eclipse Contributor agreement please? (this is not a CLA, it is just there to guarantee that you are authorized to make this contribution) |
@Geal Apologies for the delay. I've signed the agreement now. |
I was expecting a change as a return None for the comment of @Geal but I think it is okay and it makes sense keeping like this for understanding. |
Gotcha. I could change it if you like. I left it like this because the rust version behaves the same way. |
4 participants
Changes are best reviewed commit-by-commit.
UnverifiedBiscuit.UnverifiedBiscuitwith external key accessors.