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

The scope of the VC-HTTP API spec may still be an obstacle to consensus.
Here's a series of statements that might clarify things for some of us:

S1 - Data minimization is important for both security and privacy.

S2 - An Issuer, acting as a secure resource server for a VC, has an
identity-based relationship with the Subject of the VC.

S3 - The Subject, authenticates to the Issuer to receive an authorization
token to a VC.

S4 - Data minimization requires that no further information be shared with
the Issuer in order for the Issuer to provide an access token. . In other
words, the Issuer SHOULD not know, in advance, anything about the client
that will be presenting an authorization token.

S5 - Data minimization requires that the authorization token allow for
attenuation by the Subject.

S6 - The mechanism of attenuation or delegation by the Subject is out of
scope for VC-HTTP API.

If you take issue with any of these, please let us know.

- Adrian

On Wed, Jul 14, 2021 at 4:02 PM Justin Richer <jricher@mit.edu> wrote:

> 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> 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]
>> 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/
>> 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) 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
>>
>
>