Request/Share Interaction Response

[JaceHensley]

The response the user gives the relying party is a JWT in the Offer/Claim interaction but it's a VP for the Request/Share interaction. The reason behind this was because a VP is already singed and it's signed with the challenge. But this makes the interactions non-symetric.

Should this be changed so that the user responds with a JWT that contains the VP?

Cons:

• It would be a little more verbose
• The VP would be signed with the same challenge the JWT is signed with

Pros:

• Agnostic of the way the VP is signed (LD vs JWT)
• The two interactions (request and offer) would have the same flow (request jwt => response jwt)

[edhedges]

@JaceHensley This was something I had mentioned when we were collaborating on it. Can you elaborate on what you mean by "the VP would be signed with the same challenge the JWT is signed with"? Would the VP require this or would it simply require a signature by the public keys private key?

I personally think symmetry would be more appropriate from a protocol perspective because you can change the contents of the container (maybe it supports something that isn't a VP?) without changing spec.

[JaceHensley]

So the VP needs a "fresh" challenge to be signed and it makes sense for that to be the challengeToken the relying party sent to the user. But the JWT, that contains the VP, also needs to be signed. If the VP didn't have the challenge then it could be an old VP and doesn't prove current ownership, and if the JWT didn't have the challenge it wouldn't be symmetric with the other interactions.

Yeah that's what I'm thinking too, making all WACI interactions should have a challengeToken and a responseToken that contains the challengeToken makes it easier to add other interactions if we ever need to

[JaceHensley]

I'm gonna move forward with this, we can come back to the double challenge another time