Replies: 2 comments 6 replies
-
In general, UCANs, unlike traditional access keys, aren't just valid or invalid: I think the fact that we have a bunch of utilities for checking different things about UCANs with a more ore less yes/no answer other than checking for capabilities has been extremely confusing for users.
I'm sorry I know that this doesn't really help with the naming discussion here, and I have wisdom for how to determine good names, but I think it's a related thought. Reducing the API surface area is a way of making it easier for users to consume ts-ucan just like better names are :) (And sorry for polluting the API surface area when I was working on ts-ucan so far 👀 ) |
Beta Was this translation helpful? Give feedback.
-
One consideration when selecting names is familiarity. What names do developers know from using other auth libraries? A quick search of NPM with some manual filtering ranks these libraries as the most widely used (by weekly download), general purpose JWT libraries:
We should consider the context developers have from using these libraries. On the other hand, we don't need to mimic the names they use exactly. UCAN is different, and we should frame our names accordingly. |
Beta Was this translation helpful? Give feedback.
-
We've discussed on a couple of occasions which names
ts-ucan
should use for functions that check UCANs. This discussion aims to bring the considerations together and discuss them all in one place.We need some name to discuss the general concept, and I've chosen the term "check" because it seems sufficiently generic to cover nearly anything. We can consider an alternative term if we find "check" frames the discussion in an unproductive way.
What can we check?
We can check if a UCAN is
header
,payload
, andsignature
can be decoded and are separated by.
.header
andpayload
. All fields in theheader
andpayload
are correctly typed.nbf
time is in the future.exp
time has passed.nbf
is in the past and theexp
is in the future.header
+payload
was signed by the the issuer.Some UCAN checks are specific to one capability
nbf
toexp
time bounds on the UCAN fall within the time bounds of a proof that delegates the capability.We can safely use a capability that checks out even if other capabilities in a UCAN do not.
What names do we use now?
validate
ts-ucan/src/token.ts
Lines 286 to 304 in 2debb4e
isExpired
ts-ucan/src/token.ts
Lines 339 to 346 in 2debb4e
isTooEarly
ts-ucan/src/token.ts
Lines 348 to 356 in 2debb4e
Chained.fromToken
ts-ucan/src/chained.ts
Lines 22 to 34 in 2debb4e
hasCapability
ts-ucan/src/attenuation.ts
Lines 184 to 195 in 2debb4e
canDelegate
ts-ucan/src/attenuation.ts
Lines 81 to 99 in 2debb4e
We have an issue open for an unsafe decoding function: #62
Discuss
A few initial questions that we can consider
Beta Was this translation helpful? Give feedback.
All reactions