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
This feature keeps coming up: attestations. SPKI and verifiable credentials are closely related, but separate. I initially thought that this was a confusion about capabilities, but more recently some of these conversations have been with folks that definitely understand the distinction.
Technically speaking, you could use the facts (fct) field for this today. Conceptually, there is some advantage to breaking this out into its own field. It shows the UCAN author's intention, and being in the spec signals that this is a thing that's possible (and that there's a well-understood way to do it) rather than rolling your own.
The main downside is that it's more than one responsibility: what you can do, and information about a DID. Today we say "DIDs are who you are, UCAN is what you can do", which is simple.
Why do this all in one place? Sometimes you want to extend your attestations to another public key with a capability mechanism. This both breaks the capabilities-only idea, but also is a capability from a service provider that different from an attestation? The statements "Alice can send from this email" and "I assert that Alice is the sender of email from this address" are not that far off from "I assert that Alice is over 18 years old [and thus allowed to vote]".
There's no pressing need for this immedietly, but worth thinking more about as it's been coming up since day one.
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
-
This feature keeps coming up: attestations. SPKI and verifiable credentials are closely related, but separate. I initially thought that this was a confusion about capabilities, but more recently some of these conversations have been with folks that definitely understand the distinction.
Technically speaking, you could use the facts (
fct
) field for this today. Conceptually, there is some advantage to breaking this out into its own field. It shows the UCAN author's intention, and being in the spec signals that this is a thing that's possible (and that there's a well-understood way to do it) rather than rolling your own.The main downside is that it's more than one responsibility: what you can do, and information about a DID. Today we say "DIDs are who you are, UCAN is what you can do", which is simple.
Why do this all in one place? Sometimes you want to extend your attestations to another public key with a capability mechanism. This both breaks the capabilities-only idea, but also is a capability from a service provider that different from an attestation? The statements "Alice can send from this email" and "I assert that Alice is the sender of email from this address" are not that far off from "I assert that Alice is over 18 years old [and thus allowed to vote]".
There's no pressing need for this immedietly, but worth thinking more about as it's been coming up since day one.
Beta Was this translation helpful? Give feedback.
All reactions