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

Fix DIFPresFormatHandler returning invalid V20PresExRecord on presentation verification #1645

Merged
merged 7 commits into from Apr 6, 2022

Conversation

rmnre
Copy link
Contributor

@rmnre rmnre commented Feb 24, 2022

We noticed that a V20PresExRecord which is returned by the present-proof v2.0 /verify-presentation endpoint does not match its schema when DIF format is used to request a presentation. Because of this, parsing it into a Kotlin class fails:
com.squareup.moshi.JsonDataException: Expected one of [true, false] but was True at path $.verified

Fixed this by applying json.dumps() when setting pres_ex_record.verified - just like it's done in the indy handler.

However, couldn't verified be a boolean instead of a string? I found comments in the schema and in the indy handler saying it has to be a string to be used as a tag (that was my takeaway at least ;) ), but I couldn't find where it is actually declared or used that way.

Signed-off-by: Roman Reinert roman.reinert@gematik.de

@andrewwhitehead
Copy link
Member

I agree that this should be fixed, but I wonder if changing the format in a patch release would cause issues for existing controllers. @ianco maybe?

@TimoGlastra
Copy link
Member

I've seen multiple codebases that do verified == "true" because of the boolean being a string value (the better approach here is of course to parse the value, also accepting boolean values). So it should probably not be updated to a boolean value in a patch release.

@rmnre
Copy link
Contributor Author

rmnre commented Mar 2, 2022

Just to avoid confusion: This fix does not change the type of verified to boolean, it only ensures that verified is a lowercase string representation of a boolean (instead of, currently, uppercase) and therefore valid as per the schema definition of V20PresExRecord.

-Sorry, I should probably have opened another issue to bring up the question about changing it to bool in the long run.

@andrewwhitehead
Copy link
Member

Okay, I think this is probably reasonable to change then. If existing controllers are checking for == "True" then they will at least get spurious failures and not spurious verifications.

@codecov-commenter
Copy link

codecov-commenter commented Mar 4, 2022

Codecov Report

Merging #1645 (f4690a8) into main (e77d087) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1645   +/-   ##
=======================================
  Coverage   95.50%   95.50%           
=======================================
  Files         528      528           
  Lines       32736    32737    +1     
=======================================
+ Hits        31264    31265    +1     
  Misses       1472     1472           

@swcurran
Copy link
Member

swcurran commented Mar 9, 2022

@andrewwhitehead -- given your last comment, is this OK to merge? Could you provide a line or two about what to put into the release notes about this?

Copy link
Member

@swcurran swcurran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the comments and that this is for W3C VC use cases, approving this.

@ianco
Copy link
Member

ianco commented Apr 5, 2022

I agree that this should be fixed, but I wonder if changing the format in a patch release would cause issues for existing controllers. @ianco maybe?

I think this change is ok, controllers that do case-sensitive compares of the verified value will need to be fixed, not a big deal.

@andrewwhitehead andrewwhitehead merged commit 08b83af into hyperledger:main Apr 6, 2022
@rmnre rmnre deleted the fix/difpreshandler-verified branch September 13, 2022 09:12
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

Successfully merging this pull request may close these issues.

None yet

6 participants