You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AES256-GCM session key MUST be included in the "facts" (fct) field.
If we have a calculated shared secret as the session key, I don't think that we need to include it in the UCAN, the only thing you need to attest to is the tempDID from the provider.
My instinct is to send as the session negotiation a message that includes the providers tempDID as well as the specified UCAN with no att & the providers tempDID as the audience. This seems to match the same authn/authz guarantees as the specified protocol over RSA. Thoughts?
If this seems reasonable, this could be good food for thought for a more fleshed out spec that allows for different key sharing algos.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm doing AWAKE with Elliptic curve keys as the temp keys (NIST P-256 to be precise, still from WebCrypto).
With ECDH, you can calculate a shared secret between two keypairs. Is it reasonable to use this as the session key?
The whitepaper says:
If we have a calculated shared secret as the session key, I don't think that we need to include it in the UCAN, the only thing you need to attest to is the tempDID from the provider.
My instinct is to send as the session negotiation a message that includes the providers tempDID as well as the specified UCAN with no
att
& the providers tempDID as the audience. This seems to match the same authn/authz guarantees as the specified protocol over RSA. Thoughts?If this seems reasonable, this could be good food for thought for a more fleshed out spec that allows for different key sharing algos.
Beta Was this translation helpful? Give feedback.
All reactions