UCAN Working Group
Replies: 3 comments 1 reply
-
|
@alanhkarp Ah! Perhaps to clarify: in a lot of cases, we don't have a "resource server", for example my writing the DID to a If that makes sense, I can reword to make it clearer! |
Beta Was this translation helpful? Give feedback.
-
|
(Also, I'd still love to schedule some time to pick your brain about a couple things. My schedule is pretty wild the next ~2.5 weeks, let's find some time afterwords!) |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand what "self verifying" means. Some entity, what I called
the verifier, has to make sure that the delegations are valid.
That being said, whoever creates the resource produces the root UCAN. That
may be you in your use case, but things are simpler if there is a resource
server and it creates the root UCAN.
…--------------
Alan Karp
On Tue, Sep 20, 2022 at 3:58 PM Brooklyn Zelenka ***@***.***> wrote:
@alanhkarp <https://github.com/alanhkarp> Ah! Perhaps to clarify: in a
lot of cases, we don't have a "resource server", for example my writing the
DID to a .well-known path inside a data structure. This means that one
DID may control n resources, but they're self verifying.
If that makes sense, I can reword to make it clearer!
—
Reply to this email directly, view it on GitHub
<#109 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFAT47HXJTMYG5YNVCNDHDV7I6QFANCNFSM6AAAAAAQROAQSY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
My calendar is anything but wild, just the way I like it. I can usually
make time on short notice if one of your meetings gets canceled. The only
time I'm not free is Friday mornings 10-12 Pacific when our capability
group meets.
…--------------
Alan Karp
On Tue, Sep 20, 2022 at 3:59 PM Brooklyn Zelenka ***@***.***> wrote:
(Also, I'd still love to schedule some time to pick your brain about a
couple things. My schedule is pretty wild the next ~2.5 weeks, let's find
some time afterwords!)
—
Reply to this email directly, view it on GitHub
<#109 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFAT47BDXVLGXFP5QJMYXDV7I6TXANCNFSM6AAAAAAQROAQSY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Section 6.2 of the spec shows an example where the root certificate for a resource is signed by the resource owner. That means that the verifier will have to keep track of the public keys of all the owners. That job would be simpler if the root certificate were created by the resource server and the user got a delegation of it. Then the verifier would only need to track the public keys of the resource servers.
An added benefit is that there may be administrative functions at the resource server, e.g., audit, performance monitoring, that should be granted to a system administrator but not the owner. The root certificate can contain both sets of permissions, with one subset being delegated to the user and the other to an administrator.
One way to look at it is who has a "contract" with whom. The verifier and the resource server have one, and the user and resource server have another one. Note that there is no such relationship between the user and the verifier. What is currently in Section 6.2 obscures this fact.
Beta Was this translation helpful? Give feedback.
All reactions