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

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>