- From: Alan Karp <alanhkarp@gmail.com>
- Date: Sun, 4 Apr 2021 18:22:24 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Received on Monday, 5 April 2021 01:22:49 UTC
On Sun, Apr 4, 2021 at 2:39 PM Manu Sporny <msporny@digitalbazaar.com> wrote: > > > 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