-
Notifications
You must be signed in to change notification settings - Fork 198
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
feat: negotiation and auto accept credentials #336
Conversation
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>
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
There was a problem hiding this 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.
I understand what you mean, but |
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor nits
There was a problem hiding this 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>
@jakubkoci could you take a look? |
@TimoGlastra Yes, I'll do it, first thing tomorrow morning :) |
@blu3beri can you resolve the conflicts? |
Awesome! :) |
…redential Signed-off-by: Berend Sliedrecht <berend@animo.id>
Tests are currenlty failing due to merging. Will resolve asap. |
There was a problem hiding this 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
:)
) | ||
|
||
if (autoAccept === AutoAcceptCredential.Always) { | ||
return true |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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:
- The user has accepted the credential once (offer or proposal)
- 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.
There was a problem hiding this comment.
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 😄
Ah, sorry, I missed this "it has to be accepted once" in the explanation of |
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
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 |
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
“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:
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. |
There was a problem hiding this 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.
Yes, you only automate the flow for your agent. When negotiation starts,
I think so yeah, this could happen with negotiation. I do think that the documentation is a bit lacking and unclear. |
This allows for negotiation between the holder and the issuer via the
negotiateOffer
andnegotiateProposal
functions onagent.credentials
.It also allows for auto accept of credentials. the
autoAcceptCredentials
can be set on theagent
itself or on a specificcredentialRecord
where thecredentialRecord
has priority.The
autoAcceptCredential
has three states:always
,contentApproved
andnever
wherenever
is the default.always
: This means that any credential, no matter from who is automatically accepted (even if the attributes orcredentialDefinitionId
changed).contentApproved
: This means that when a credential is received it has to be accepted once and the attributes andcredentialDefinitionId
did not change. If something did change it will not automate the flow.never
: This simply means that no credentials are automatically accepted.