W3C home > Mailing lists > Public > public-credentials@w3.org > April 2021

Re: The ezcap-express library

From: Alan Karp <alanhkarp@gmail.com>
Date: Sun, 4 Apr 2021 18:22:24 -0700
Message-ID: <CANpA1Z21XYD+mZWGcvZb8XwUe9oukhXHfenLvC6JeYHqoWZCuw@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On Sun, Apr 4, 2021 at 2:39 PM Manu Sporny <msporny@digitalbazaar.com>

> > The standard approach is to use the capability to both designate and
> > authorize.
> Yes, which is what is being done, I believe.

I see what you're doing.  It's similar to OAuth 2, with the URL as the
address and the bearer token in the authorization header.  In both the
token designates the resource at the specified URL.  In both it's possible
to send the token to the wrong URL.  There's a risk in OAuth 2 if it's a
bearer token, but there's no risk in your case because the capability is
issued to a public key.  Did I get that right?

> What am I missing? I don't know if we're on the same page or not? :)

There may also be an issue like the one Dick Hardt talked about at IIW a
couple of years ago.  In his case, there was a vulnerability when there was
more than one authorization server for a resource.  I don't recall the
details, but his solution was to include the URL in the token.  You can do
the same thing.  Your library code can pull out the URL for invocations.
Doing so will simplify the API for slightly more complex situations, such
as when you need to specify two resources.

Alan Karp
Received on Monday, 5 April 2021 01:22:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:13 UTC