PROPOSAL: Define Client Credentials for APIs about traceability-interop HOT 11 CLOSED

100% agree with this approach!

We could advocate that people list their endpoints for the VC HTTP API and the authorization in the DID docs of the organizations did doc and put that into the well-known path for discoverability. then the only thing that remains is the identity set up of A and B in each other's apps. But that can follow the already known and used methods that enterprises love and cherish. cc @OR13 @mprorock

from traceability-interop.

On the call today, we discussed 2 options regarding access_token and scope.

Consensus was too not put scopes into the flow, until the API is more mature/

from traceability-interop.

I like this flow - OAuth works well in this case and the way you are lining out the /organizations/... path sets things up well for the multi-tenant situations we are seeing in the real world

from traceability-interop.

thanks, I think we already have evidence that some vc http api endpoints will be isolated and authenticated on a per tenant basis, whether thats via a subdomain or a path.

obviously it's frustrating to build and maintain so many point to point integrations... but this is what folks doing api integrations today expect, and we will be shooting ourselves in the face to start with anything else IMO.

from traceability-interop.

nb: closely related to #3

from traceability-interop.

great note from @TallTed on weekly call that auth should likely apply to all APIs in this spec

from traceability-interop.

partially addressed in #15

Would love to work postman test for this: #16

from traceability-interop.

I talked about DBMS analogies on the call; the basic web architecture also fits.

DBMS "native" API carries ODBC/JDBC/dotNET/OLE DB/etc. carries app data and/or logic of varying depths which may require varying authentication and authorization, typically to the CATALOG or SCHEMA or TABLE or ROW or even CELL.

TCP/IP carries TLS carries HTTP (making it HTTPS) carries app data and/or logic of varying depths which may require varying authentication and authorization, to the directory/container or file or segment of file, etc.

It's important to build to allow the very very low-level, though early efforts may only require the high level at the beginning -- with the eternal caution that some early deployments may linger for decades past their expected expiration date (note bene the FORTRAN and COBOL that still powers the financial industry, not to mention [if I remember right] still-lingering pieces of the air-traffic-control system!) ... so always be careful what optionals you put default credentials into!

from traceability-interop.

related:

• https://swagger.io/specification/
• https://swagger.io/docs/specification/authentication/

from traceability-interop.

implemented in spec, pending close once new issue addressing the links above is raised.

from traceability-interop.

Opened, here: w3c-ccg/vc-api#218

from traceability-interop.