JCL-299: verify method - #403
timea-solid merged 7 commits into
Conversation
Sorry, something went wrong.
| return v1Metadata().thenCompose(metadata -> { | ||
|
|
||
| final Map<String, Object> presentation = new HashMap<>(); | ||
| presentation.put(VERIFIABLE_CREDENTIAL, accessGrant); |
There was a problem hiding this comment.
The /verify endpoint can also take a VerifiablePresentation. Do you need this in this client?
Sorry, something went wrong.
| if (isSuccess(status)) { | ||
| return processVerificationResult(input); | ||
| } | ||
| throw new AccessGrantException("Unable to perform Access Grant verify: HTTP error " + status, |
There was a problem hiding this comment.
In the case of an error the response will also contain an error, errorDescription and an optional reason. These could be useful for a downstream client to know but they are getting dropped here and we are only giving them the status.
Sorry, something went wrong.
There was a problem hiding this comment.
According to the VC-API spec, the verify endpoint will return a 200 in cases where the credential is invalid, but there is no defined response for, say, 4xx or 5xx category errors.
I think it would be great for the client to try to parse 4xx/5xx error bodies as if they contain those response, but that can be part of an overall improvement in how errors are processed.
Sorry, something went wrong.
acoburn
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
| if (isSuccess(status)) { | ||
| return processVerificationResult(input); | ||
| } | ||
| throw new AccessGrantException("Unable to perform Access Grant verify: HTTP error " + status, |
There was a problem hiding this comment.
According to the VC-API spec, the verify endpoint will return a 200 in cases where the credential is invalid, but there is no defined response for, say, 4xx or 5xx category errors.
I think it would be great for the client to try to parse 4xx/5xx error bodies as if they contain those response, but that can be part of an overall improvement in how errors are processed.
Sorry, something went wrong.
@jholleran Could you please take a look at the verify(...) method I added. I understand there are options in the call. What can they be? is it different from access grant to access request?
Any help is welcome.
Conclusion: we took out options from call.