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

Re: VC HTTP API Telecon Minutes for 2021-07-13

From: Justin Richer <jricher@mit.edu>
Date: Wed, 14 Jul 2021 16:01:00 -0400
Message-Id: <DD0660ED-8336-4B56-9697-FF6E3EBE846A@mit.edu>
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
To: Alan Karp <alanhkarp@gmail.com>
I’m saying something separate but related:

Before you can even think about delegating rights, you have to define the rights that can be delegated, whether that delegation happens to a piece of software, to another person, or anything else. 

I think that defining OAuth 2 with client credentials :in this spec: is a mistake because it allows this very important question to be ignored until it’s too late and there are already several competing proprietary solutions.

 — Justin

> On Jul 13, 2021, at 11:22 PM, Alan Karp <alanhkarp@gmail.com> wrote:
> As I understand it, RAR is a way to express the desire for an access token with a subset of the permissions the requester is entitled to, but what if the client wants to delegate those permissions?  It will have to share its client secret if there's no way to delegate.  That's why I say that OAuth 2 with client credentials and no delegation is a mistake.
> --------------
> Alan Karp
> On Tue, Jul 13, 2021 at 7:31 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> Agreed, and it's exactly that "limitation of authority" that RAR is set to solve in an interoperable way. If we don't solve it here, it's going to be solved in a hundred worse ways. 
> -Justin
> ________________________________________
> From: Alan Karp [alanhkarp@gmail.com <mailto:alanhkarp@gmail.com>]
> Sent: Tuesday, July 13, 2021 8:58 PM
> To: Manu Sporny
> Cc: W3C Credentials CG
> Subject: Re: VC HTTP API Telecon Minutes for 2021-07-13
> Adrian Gropper:  Just to make sure how we are using Client
>   Credentials: does that mean there can be no delegation?
> <justin_richer> yes, that's exactly what that means
>   ... by the whoever is in control of the credential - whether
>   the subject (typically)...
>   ... Is this making a statement on the ability to delegate?
> Orie Steele: https://oauth.net/2/grant-types/client-credentials/ <https://oauth.net/2/grant-types/client-credentials/>
> Manu Sporny:  It is saying you cannot delegate if you are using
>   OAuth2 Client Credentials, but not saying you can't use another
>   protocol than Client Credentials
> There is a long history of trying to prevent delegation, SPKI (https://datatracker.ietf.org/doc/html/rfc2692 <https://datatracker.ietf.org/doc/html/rfc2692>) being the most notable.  The RFC even says, "but there's nothing to stop someone who wishes to delegate against the rules from also loaning out their private key."  The inability to prevent credential sharing means that blocking delegation results in a system that is harder to use, because people must use ad hoc mechanisms to share the credentials, and less secure, because people end up granting much more authority than they need to.
> --------------
> Alan Karp

Received on Wednesday, 14 July 2021 20:01:18 UTC

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