Re: [AGENDA] VC HTTP API Work Item - July 13th 2021

Orie Steele <orie@transmute.industries> wrote:

> All instances of the API that I have seen in operation, and the current API structure for the "Issuer" endpoints, imply that the APIs are bound to some "internal identifier"...
>
> This becomes obvious when you see this test:
>
> https://github.com/w3c-ccg/vc-http-api/blob/main/packages/vc-http-api-test-server/__tests__/issueCredential.spec.js#L114
>
> This means that there is a "default key" used to support issuance.
>
> Who controls that key? The API origin.
>
> All of the endpoints except those related to "Presentation Exchange" are in the same category of being bound to an internal identifier, either the raw origin or some path based tenant such as:
>
> agent-42.example.com or example.com or /organizations/123 or /tenant/123 or /agent/123 or or /wallet/123... this is the entity who has a "default key".
>
> We don't need to support delegating issuance capabilities to these endpoints, because they are not meant to be invoked outside of the same trust domain.
>
> I think this sentence may be the cause of my confusion.  It sounds like
you are talking about delegating permission to issue access tokens.  I am
talking about a holder of an access token being able to delegate a subset
of its permissions to someone else.

--------------
Alan Karp


On Sun, Jul 11, 2021 at 3:50 PM Orie Steele <orie@transmute.industries>
wrote:

> PROPOSAL: How a VC HTTP API client gets an authorization token is out of scope.
>
> -1 (for now, maybe after we make some progress with reduced scope / client credentials only for a start...)
>
> PROPOSAL: How a VC HTTP API server validates an authorization token is out of
> scope.
>
> +1
>
> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API MUST be
> OAuth 2 Bearer tokens.
>
> +1
>
> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API SHOULD be
> GNAP key-bound access tokens.
>
> -1
>
> PROPOSAL: One of the authorization protocols for the VC-HTTP-API MUST be OAuth
> 2 Client Credentials. NOTE: This one conflicts with the first proposal (on
> purpose).
>
> +1
>
> PROPOSAL: The VC HTTP API MUST define access actions in terms of OAuth 2 RAR
> structures.
>
> -1
>
> I forgot to hit send on this weeks ago, luckily we haven't made any progress, so little is lost...
> See the traditional approach summarized here:
>
> https://auth0.com/blog/on-the-nature-of-oauth2-scopes/
>
> "TL;DR: Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user: a scope cannot allow an application to do more than what the user can do."
>
> Now let's ask the questions:
>
> 1. Do we need to support delegation?
> 2. How are the VC-HTTP-APIs invoked... are they called by "users" or "applications"?
>
> I don't believe the VC-HTTP-API needs to support delegation.
>
> All instances of the API that I have seen in operation, and the current API structure for the "Issuer" endpoints, imply that the APIs are bound to some "internal identifier"...
>
> This becomes obvious when you see this test:
>
> https://github.com/w3c-ccg/vc-http-api/blob/main/packages/vc-http-api-test-server/__tests__/issueCredential.spec.js#L114
>
> This means that there is a "default key" used to support issuance.
>
> Who controls that key? The API origin.
>
> All of the endpoints except those related to "Presentation Exchange" are in the same category of being bound to an internal identifier, either the raw origin or some path based tenant such as:
>
> agent-42.example.com or example.com or /organizations/123 or /tenant/123 or /agent/123 or or /wallet/123... this is the entity who has a "default key".
>
> We don't need to support delegating issuance capabilities to these endpoints, because they are not meant to be invoked outside of the same trust domain.
>
> All of the pictures we have seen related to use cases confirm this.
>
> In those pictures a user interacts with an agent or a wallet, which in turn calls one of these APIs... It is understood that the agent or wallet is an "application" not a "user".
>
> See the summary at the end of the Auth0 article:
>
> "Again in the general case, overloading scopes to represent actual privileges assigned to the app (as opposed to the delegated permissions mentioned above) is problematic — as it requires the AS to have specialized authorization knowledge at a granularity that is often not practical to achieve and maintain; even in the case in which that’s viable, the increase in traffic and token size might still render the approach unfeasible."
>
> Once we begin to make the AS aware of the nature of the VC HTTP API, a number of problems arise.
>
> Let's consider the alternative.
>
> Lets say that API implementations maintain an internal permissions system whereby they manage questions related to permissions, and don't leak their API permissions model or its use to the AS.
>
> In such a scenario, with Client Credentials, you would have the following structure:
>
> agent-42.example.com | /tenant/123 has granted CLIENT_ID the capability to issue verifiable credentials with KEY_123.
>
> This permission is enforced by authenticating CLIENT_ID and then looking up what agent-42.example.com has allowed that client to do.
>
> In a role based access control model, these kinds of permissions are often represented like this:
>
> Can a ROLE take an ACTION on a RESOURCE =>
>
> can "CLIENT_ID" "ISSUE" "Verifiable Credential"
> can "CLIENT_ID" "VERIFY" "Verifiable Presentation"
> can "CLIENT_ID" "DERIVE" "Verifiable Credential"
>
> When the API decides whether to allow or deny these invocations, one of 2 things happens:
>
> 1. the API looks at the access token and the AS knows what the CLIENT_ID can do and tells the API via the token (and the token gets absurdly large...)
> 2. the API looks only at `sub` of the access token and their internal permissions model, and the AS does not know what the CLIENT_ID can do
>
> Either will work, but as Auth0 points out:
>
> "if the AS happens to have access to data and logic that make it possible to take authorization evaluations at token issuance time, those can certainly be reflected in the decision of withholding issuance, or in the content of the issued token — but there’s no reason for the latter to be expressed in scopes claims, and doing so can in fact contribute to keep alive the urban legend that made me spend about half of a long flight writing this also long post."
>
> It is MUCH safer for us NOT to define scopes / or spend time on RAR than it is for us to require them... we can always add them later.
>
> If you want to see an example of an API that supports scopes and is built on standards widely in use today (that the vc http api is already using), take a look at:
>
> https://petstore3.swagger.io/
>
> From my perspective the safest path forward is to allow APIs to manage permissions "internally" and not to spend a lot of time on scopes or delegation, whn we can instead focus on first securing these endpoints with standards that we well supported by off the shelf tooling today.
>
> Today the API has no security, it's a root account with no password.
>
> First step should be giving root a password, second step should be not using root account for everything.
>
> I am a strong -1 to continuing to discuss "delegation"... we resolved not to discuss GNAP as a "SHOULD or a MUST"... now we are talking about trying to enable GNAP implicitly by making the delegation scenarios 100% compatible with it...
>
> Why not embrace the community that has been built around OAuth2? Microsoft, Google, Okta, Auth0, Ping, ForgeRock, etc...
>
> Why go to war with them in a community group when they are the reality in the enterprise api market today?
>
> If folks want to design this API in a way that makes it impossible for use with popular API  off the shelf authorization products today, and that drives traffic and attention to emerging standards supported by small companies, but not supported by large companies... I have to object.
>
> I am here to build a bridge to existing communities, I don't want to start by insulting folks grounded in current enterprise api security reality (OAuth2.0), and then spend my time building a bridge to an island with a few startups and some UK banks, even if that really is the future of enterprise api security... give it time to be visibly the biggest pond, don't ask us to believe it will grow to be the biggest pond.
>
> - https://github.com/oauthstuff/draft-oauth-rar
> - https://es.slideshare.net/TorstenLodderstedt/rich-authorization-requests
> - https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
> - https://openid.net/2021/04/14/guest-blog-financial-grade-api-fapi-explained-by-an-implementer-updated/
> - https://www.forgerock.com/industries/financial-services/open-banking/UK-Spec
>
> There is nothing wrong with RAR or GNAP... There is a lot wrong with making them a dependency, and telling folks the VC-HTTP-API is built on widely adopted and mature internet standards.... The VC Data Model is already a stretch in this regard.
>
> "Where are RAR, PAR, and JAR in the standardization process?"
>
> https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/c2c23243
>
> PROPOSAL 1: The VC HTTP API will describe OAuth2.0 client credentials grant authentication for applications as described here https://datatracker.ietf.org/doc/html/rfc6749#section-4.4, https://developer.okta.com/docs/guides/implement-client-creds/overview/, https://auth0.com/machine-to-machine. ...This is the same as:
>
> PROPOSAL: One of the authorization protocols for the VC-HTTP-API MUST be OAuth
> 2 Client Credentials. NOTE: This one conflicts with the first proposal (on
> purpose).
>
>
> OS
>
>
> On Sat, Jul 10, 2021 at 10:13 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> VC HTTP API Work Item - July 13th 2021
>> Time: Tue 4pm ET, 1pm PT, 10pm CET, 8am NZDT (Wed)
>>
>> Text Chat:
>>       http://irc.w3.org/?channels=ccg
>>       irc://irc.w3.org:6665/#ccg
>>
>> Jitsi Teleconf:
>>       https://meet.w3c-ccg.org/vchttpapi
>>
>> Duration: 60 minutes
>>
>> MEETING MODERATOR: Manu Sporny
>>
>> AGENDA:
>>
>> 1. Agenda Review, Introductions, Use Cases Update (10 min)
>>
>> 2. Pull Requests (5 minutes)
>>    https://github.com/w3c-ccg/vc-http-api/pull/211
>>
>> 3. Issue Processing (5 minutes)
>>    https://github.com/w3c-ccg/vc-http-api/issues/204
>>
>> 4. Authorization Proposals (40 minutes)
>>
>> These are synthesized proposals based on Justin's reformulation of MikeV's
>> proposals, the +1s on the mailing list, work that has volunteers, and
>> ideas
>> that seem like they might at least get majority support given input from
>> the
>> mailing list.
>>
>> PROPOSAL: How a VC HTTP API client gets an authorization token is out of
>> scope.
>>
>> PROPOSAL: How a VC HTTP API server validates an authorization token is
>> out of
>> scope.
>>
>> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API MUST be
>> OAuth 2 Bearer tokens.
>>
>> PROPOSAL: One of the authorization mechanisms for the VC-HTTP-API SHOULD
>> be
>> GNAP key-bound access tokens.
>>
>> PROPOSAL: One of the authorization protocols for the VC-HTTP-API MUST be
>> OAuth
>> 2 Client Credentials. NOTE: This one conflicts with the first proposal (on
>> purpose).
>>
>> PROPOSAL: The VC HTTP API MUST define access actions in terms of OAuth 2
>> RAR
>> structures.
>>
>> In the interest of making some preliminary decisions and moving on, we
>> will be
>> doing majority voting for all proposals that fail to achieve consensus.
>> Remember that all of this is at risk to being re-litigated when the work
>> flows
>> into an official working group, so decisions are to be viewed as
>> preliminary
>> (and not final).
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> News: Digital Bazaar Announces New Case Studies (2021)
>> https://www.digitalbazaar.com/
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>