-
Notifications
You must be signed in to change notification settings - Fork 23
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: access agent proofs method would fail to return some session proofs #1047
Conversation
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 don't really understand how this fixes the issue.
* @returns {Record<string, Ucanto.Delegation>} | ||
*/ | ||
export function getSessionProofs(data) { | ||
export function getSessionProofs(data, issuer) { |
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.
Part of what was causing the bug is that this function ends up building a map of CIDs to proofs. The CID it uses is the nb.proof from a ucan/attest. The agent might actually have multiple ucan/attest ucans with the same nb.proof CID, but with different issuers. Previously only one of these delegations would end up in the returned map from this function, and the caller had no way of getting a session proof appropriate for the audience of their request.
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 think this is fairly low level API so I suggest a breaking change that will change return type to
Record<Ucanto.DID, Record<string, ...Ucanto.Delegation>>
That way things will work correctly even if you do not pass the issuer. Furthermore I do have use case where I query proofs
and I do not know the issuer of attestations so getting all the proofs would be desired there.
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 did something like that here a9aedf6
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.
One bit of cleanup, but I do think the proofs
method signature needs some thought - happy to chat in higher bandwidth whenever's convenient for you!
… object and options.sessionProofIssuer
…packages in monorepo, and instead uses npm to run the package's build script
…ild all packages in monorepo, and instead uses npm to run the package's build script" This reverts commit 456e6b2.
I met with @Gozala about this and he agreed it makes sense. In the medium term we both don't love the |
…service id. to avoid attestations from separate issuers having identical CID
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.
looks good, thanks!
…of just returning more proofs than are necessary in some cases
7163363
to
a9aedf6
Compare
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.
Approved with some suggestions
*/ | ||
export function getSessionProofs(data) { | ||
/** @type {Record<string, Ucanto.Delegation>} */ | ||
/** @type {Record<string, [Ucanto.Delegation, ...Ucanto.Delegation[]]>} */ |
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 ok but I would prefer Record<Ucanto.DID, Record<string, ...Ucanto.Delegation>>
per #1047 (comment) because it makes it a lot easier to pick the ones you care and throw away others as opposed to having to go and group them in another loop.
Not a big deal, but unless there is compelling reason to prefer this I would suggest reverse.
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.
@Gozala roger. I will change to that.
I assume the keys of the inner record (typed as string
) would be session proof issuer? and keys of outer record would be the attested to proof cid?
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.
did it 914405d
…-> accessConfirmInvocation per review suggestion
…ct to both proofs
…irst by sessionProof nb.proof and then by sessionProof issuer
f062abb
to
914405d
Compare
…ilter session proofs to once issuer. Agent invoke method uses it. This is required for the registerSpace request to work against staging rn
I was about to merge this, then did one last bit of testing in my local setup to make sure all this would still fix the situation for #113, but noticed that when I tried, I got a new 500 error from the backend. Two days ago I had tested and it worked. I think the regression happened because yesterday I took out the So I re-introduced |
🤖 I have created a release *beep* *boop* --- ## [16.4.0](access-v16.3.0...access-v16.4.0) (2023-11-01) ### Features * access agent proofs method would fail to return some session proofs ([#1047](#1047)) ([d23a1c9](d23a1c9)) ### Bug Fixes * use the issuer as the resource in revocation ([#992](#992)) ([7346d1f](7346d1f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
…roof selection with `w3 register space` (#114) Motivation: * make use of storacha/w3up#1047 and expect it to fix #113
🤖 I have created a release *beep* *boop* --- ## [7.1.0](upload-api-v7.0.0...upload-api-v7.1.0) (2023-11-03) ### Features * access agent proofs method would fail to return some session proofs ([#1047](#1047)) ([d23a1c9](d23a1c9)) * expose test context of upload-api ([#1069](#1069)) ([f0757d1](f0757d1)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Motivation:
Unauthorized: Claim {"can":"provider/add"} is not authorized
when trying to register space - when juggling prod/staging W3UP_SERVICE_DID w3cli#113Context
Agent#registerSpace
to fail due to invalid proofs, even if the underlying AgentData had the right proof. This was becauseregisterSpace
ends up callinginvokeAndExecute(Provider.add)
, which callsinvoke
to build the invocation, which callsproofs
to get the proofs for the invocation. Andproofs
could fail to include a sessionProof that was appropriate for the invocation audience of the invocation built byAgent#invoke
. Now,Agent#proofs
returns all the sessionProofs that might be relevant.