search

w3c-ccg / traceability-interop

Verifiable Credentials for Supply Chain Interoperability Specification for HTTP
https://w3id.org/traceability/interoperability
Other
25 stars 9 forks source link

Service endpoint discovery is pointless when client_credentials have already been exchanged #660

Closed nissimsan closed 3 days ago

nissimsan commented 1 month ago

We have trimmed the spec significantly recently, which is great and brings a lot of clarity. What remains is essentially this interoperability flow:

  1. Verifier provides Holder OAuth client credentials
  2. Holder looks up Verifiers service endpoint
  3. Holder authenticates and present to Verifier

Step 2 doesn't actually make sense any longer. The service endpoint could just be provided along with the client credentials (in step 1). It is a reminiscence of when we did on-the-fly authentication (/available).

I propose we get rid of step 2 and update the spec such that the service endpoint is exchanged along with client credentials - a standard oauth-authenticated network request.

mkhraisha commented 1 month ago

I agree with this, I'll also add i think a did resolution endpoint doesn't make sense in general, did resolution should be up to the provider, and as long as a valid credential verifies, and an invalid one does not, we should not care how they do that resolution.

TallTed commented 2 days ago

Belatedly... This may need to be reopened.

I want a clearer name and description for this feature than "holder-verifier binding".

I don't understand "Initial Party Binding".

I don't understand the implied requirement for "the Verifier to establish binding, enabling the Holder to submit data". Is this "feature" about "binding a holder to a verifier"? "binding a verifier to a holder"?

"Binding" seems entirely out of place here. What seems to be needed is some way for the Holder (presenter) to establish secure communications with the Verifier ... which doesn't seem too far removed from the need for HTTP browsers to establish secure communications with HTTP servers, which is most commonly handled today with TLS, commonly seen as HTTPS.

If, as stated above, this is a "standard OAuth-authenticated network request", the write-up in our UCR and elsewhere should say so -- and rely on OAuth, not reinvent it at a lower level.

What am I missing?