JCL-299: verify method #403
Conversation
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
access-grant/src/main/java/com/inrupt/client/accessgrant/AccessGrantClient.java
Outdated
Show resolved
Hide resolved
access-grant/src/main/java/com/inrupt/client/accessgrant/AccessGrantClient.java
Outdated
Show resolved
Hide resolved
| 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?
| 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.
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.
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
timea-solid
temporarily deployed
to
ESS PodSpaces
GitHub Actions
Inactive
| 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.
@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.