Discovery Service: change client to manage subjects, not DIDs #3294
Conversation
gerardsn
force-pushed
the
iss-3265/discovery-management-using-subjects
branch
from
93ea745 to
91291a1
Compare
gerardsn
force-pushed
the
iss-3265/discovery-management-using-subjects
branch
from
91291a1 to
1e19f39
Compare
discovery/client.go
Outdated
| for _, subjectDID := range subjectDIDs { | ||
| err := r.registerPresentation(ctx, subjectDID, service) | ||
| if err != nil { | ||
| loopErrs = append(loopErrs, err) |
There was a problem hiding this comment.
you might want to distinguish between functional errors and technical errors. A functional error like CredentialNotFound can be ignored, but a socket timeout should be logged.
There was a problem hiding this comment.
I've made an attempt to add this, but it is ugly. I'm happy to change it if you have a better idea
discovery/store.go
Outdated
|
|
||
| // getSubjectVPsOnService finds all VPs in the service that contain a credential issued to any of the subjectDIDs. | ||
| // It returns a (potentially empty) list of VPs for each of the subjectDIDs. | ||
| // The list should not contain retractions since these do not contain any credentials. |
There was a problem hiding this comment.
but in client.go there's a check on retraction type. So does the list contain retractions or not? Also returning a map might be better suited?
There was a problem hiding this comment.
but in client.go there's a check on retraction type. So does the list contain retractions or not?
'should' is not an acceptabel word to describe the result of a function, so removed the line. My confusion stems from the implementation not matching our own spec #3298
Also returning a map might be better suited?
now returns a map. Not sure if it should contain the keys for DIDs that do not have a VP
fixes #3265
This change lets the Discovery Service client manage Subjects rather than individual DIDs.
During activation/refresh it tries to register every DID in a subject. If 1 DID is successfully registered on the service, the operation is considered successful and a refresh is scheduled at 45% of the max_presentation_validitiy. This means that if a second DID fails that should not fail, it will not be retried until the next scheduled refresh. So it will be retried again at 90% of max_presentation_validity. If everything fails, the refresh/activation will be retried at the next configured refresh interval.