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

feat: negotiation and auto accept credentials #336

Conversation

berendsliedrecht
Copy link
Contributor

This allows for negotiation between the holder and the issuer via the negotiateOffer and negotiateProposal functions on agent.credentials.

It also allows for auto accept of credentials. the autoAcceptCredentials can be set on the agent itself or on a specific credentialRecord where the credentialRecord has priority.

The autoAcceptCredential has three states: always, contentApproved and never where never is the default.

always: This means that any credential, no matter from who is automatically accepted (even if the attributes or credentialDefinitionId changed).
contentApproved: This means that when a credential is received it has to be accepted once and the attributes and credentialDefinitionId did not change. If something did change it will not automate the flow.
never: This simply means that no credentials are automatically accepted.

Signed-off-by: blu3beri <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>

added check assert instead of try catch

Signed-off-by: Berend Sliedrecht <berend@animo.id>

Moved the else statement

Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
@berendsliedrecht berendsliedrecht requested a review from a team as a code owner June 29, 2021 14:34
@codecov-commenter
Copy link

codecov-commenter commented Jun 29, 2021

Codecov Report

Merging #336 (19a9ed0) into main (d35ede5) will increase coverage by 0.32%.
The diff coverage is 90.25%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #336      +/-   ##
==========================================
+ Coverage   88.01%   88.34%   +0.32%     
==========================================
  Files         237      239       +2     
  Lines        4624     4796     +172     
  Branches      571      615      +44     
==========================================
+ Hits         4070     4237     +167     
- Misses        554      559       +5     
Impacted Files Coverage Δ
src/modules/proofs/services/ProofService.ts 86.74% <ø> (ø)
src/types.ts 100.00% <ø> (ø)
...s/credentials/handlers/ProposeCredentialHandler.ts 76.00% <70.00%> (-24.00%) ⬇️
...les/credentials/handlers/IssueCredentialHandler.ts 89.47% <85.71%> (-10.53%) ⬇️
...les/credentials/handlers/OfferCredentialHandler.ts 89.47% <85.71%> (-10.53%) ⬇️
...s/credentials/handlers/RequestCredentialHandler.ts 89.47% <85.71%> (-10.53%) ⬇️
...dules/credentials/CredentialResponseCoordinator.ts 93.42% <93.42%> (ø)
src/modules/credentials/CredentialsModule.ts 90.74% <93.93%> (+3.08%) ⬆️
src/agent/AgentConfig.ts 94.91% <100.00%> (+0.27%) ⬆️
...rc/modules/credentials/CredentialAutoAcceptType.ts 100.00% <100.00%> (ø)
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d35ede5...19a9ed0. Read the comment docs.

Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

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

This is really great @blu3beri! Please see my suggestions.

One thing I didn't mention in the comments yet, is that . We said that CredentialRecord.credentialAttributes would be the source of truth on our interpretation of what we expect to issue or get issued. Currently e.g. processCredential overwrites this value. This should only happen if we agreed to this proposal. Could you go over all methods in the module/service/handlers and make sure credentialAttributes is always what we see as the source of truth? I'm open to other approaches.

src/modules/credentials/CredentialUtils.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialUtils.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialsModule.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialsModule.ts Outdated Show resolved Hide resolved
src/modules/credentials/handlers/IssueCredentialHandler.ts Outdated Show resolved Hide resolved
src/modules/credentials/handlers/IssueCredentialHandler.ts Outdated Show resolved Hide resolved
src/modules/credentials/handlers/IssueCredentialHandler.ts Outdated Show resolved Hide resolved
src/types.ts Outdated Show resolved Hide resolved
src/__tests__/credentials-autoAccept.test.ts Outdated Show resolved Hide resolved
src/__tests__/credentials-autoAccept.test.ts Outdated Show resolved Hide resolved
@berendsliedrecht
Copy link
Contributor Author

This is really great @blu3beri! Please see my suggestions.

One thing I didn't mention in the comments yet, is that . We said that CredentialRecord.credentialAttributes would be the source of truth on our interpretation of what we expect to issue or get issued. Currently e.g. processCredential overwrites this value. This should only happen if we agreed to this proposal. Could you go over all methods in the module/service/handlers and make sure credentialAttributes is always what we see as the source of truth? I'm open to other approaches.

I understand what you mean, but processCredential does not overwrite the credentialAttributes. Am I missing something or did you mean another function?

@TimoGlastra
Copy link
Contributor

TimoGlastra commented Jul 1, 2021

I see. Forget that method. I should look before writing...

But the point stands: only overwrite the credentialAttributes if that's our interpretation of the credential data (so not in processCredential, but do in createAck. not in processOffer, but do in createRequest)

not sure if we're already doing this.

Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
src/types.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

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

Few minor nits

Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

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

Few minor nits

Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
@TimoGlastra
Copy link
Contributor

@jakubkoci could you take a look?

@jakubkoci
Copy link
Contributor

@TimoGlastra Yes, I'll do it, first thing tomorrow morning :)

@TimoGlastra
Copy link
Contributor

@blu3beri can you resolve the conflicts?

@TimoGlastra
Copy link
Contributor

@TimoGlastra Yes, I'll do it, first thing tomorrow morning :)

Awesome! :)

…redential

Signed-off-by: Berend Sliedrecht <berend@animo.id>
@berendsliedrecht
Copy link
Contributor Author

Tests are currenlty failing due to merging. Will resolve asap.

Copy link
Contributor

@jakubkoci jakubkoci left a comment

Choose a reason for hiding this comment

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

I'm not sure if I understand ContentApproved correctly but otherwise, this seems like a nice feature.

I was struggling a bit with understanding the validation part inside CredentialResponseCoordinator :)

src/__tests__/credentials-autoAccept.test.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialAutoAcceptType.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialResponseCoordinator.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialResponseCoordinator.ts Outdated Show resolved Hide resolved
src/modules/credentials/handlers/OfferCredentialHandler.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialResponseCoordinator.ts Outdated Show resolved Hide resolved
)

if (autoAccept === AutoAcceptCredential.Always) {
return true
Copy link
Contributor

Choose a reason for hiding this comment

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

It's interesting that we don't validate the credential in this case. Does it mean that ContentApproved means the content was validated?

What's the use case when you want to accept the different values than they're in credentialAttributes? Are these credentialAttributes updated when that case happen?

I guess I don't fully understand the ContentApproved. 😕 I thought its like that the user approved the offer. I think common use case when the user doesn't want to approve credential offer automatically but after approving the offer she doesn't care about the rest of the exchange (assuming it's validated by the framework)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, so the contentApproved was to check two things:

  1. The user has accepted the credential once (offer or proposal)
  2. The content of the credential did not change (if it changed the automation will be cancelled)

I am completely open to better naming or comprehensive description at the enum.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I see. That's clear to me now, also not able to think of better naming 😄

src/modules/credentials/CredentialResponseCoordinator.ts Outdated Show resolved Hide resolved
src/modules/credentials/CredentialResponseCoordinator.ts Outdated Show resolved Hide resolved
@jakubkoci
Copy link
Contributor

Ah, sorry, I missed this "it has to be accepted once" in the explanation of ContentApproved. But does it mean accepting a credential offer?

Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
@berendsliedrecht
Copy link
Contributor Author

Ah, sorry, I missed this "it has to be accepted once" in the explanation of ContentApproved. But does it mean accepting a credential offer?

It means that once in the whole issuance flow the credential has been accepted. Whether it is a propose or offer does not matter. Also with contentApproved the attribute values and credentialDefinitionId are not allowed to change.

Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
@jakubkoci
Copy link
Contributor

Ah, sorry, I missed this "it has to be accepted once" in the explanation of ContentApproved. But does it mean accepting a credential offer?

It means that once in the whole issuance flow the credential has been accepted. Whether it is a propose or offer does not matter. Also with contentApproved the attribute values and credentialDefinitionId are not allowed to change.

“Whether it is a propose or offer does not matter”

But we need to distinguish between the roles of issuer and holder, right?. As I understand it:

  • an issuer can accept the proposal, and then the rest of the issuance is automated on the issuer side
  • a holder can accept the offer, and then the rest of the issuance is automated on the holder side

Is that correct?

I’m still unsure if it’s good that there is no validation when a developer handles the process manually. Is it a valid use case when credential definition ID is changed during the process?

Maybe we can discuss it in the AFJ call. It's not definitely a blocker for merging.

Copy link
Contributor

@jakubkoci jakubkoci left a comment

Choose a reason for hiding this comment

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

I still have some questions, but they're rather about explaining the behavior. That can be updated in documentation or comments later if needed.

@berendsliedrecht
Copy link
Contributor Author

But we need to distinguish between the roles of issuer and holder, right?. As I understand it:

* an issuer can accept the proposal, and then the rest of the issuance is automated on the issuer side

* a holder can accept the offer, and then the rest of the issuance is automated on the holder side

Is that correct?

Yes, you only automate the flow for your agent. When negotiation starts, contentApproved sees that and will cancel the automation. This credential changed detection might be nice to expose to the public API so a framework consumer could easily detect changes and alert a user.

Is it a valid use case when credential definition ID is changed during the process?

I think so yeah, this could happen with negotiation.

I do think that the documentation is a bit lacking and unclear.

@berendsliedrecht berendsliedrecht merged commit 55e8697 into openwallet-foundation:main Jul 15, 2021
@berendsliedrecht berendsliedrecht deleted the feature/auto-accept-credential branch August 31, 2022 07:18
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.

5 participants