search

w3c-ccg / traceability-interop

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

Should all DID resolution requests be unauthenticated? #187

Closed brownoxford closed 2 years ago

brownoxford commented 2 years ago

The new verifier DID resolution requests added to the presentation testing is unauthenticated - should we always make unauthenticated DID resolution requests?

@nissimsan @OR13 pinging for comment

TallTed commented 2 years ago

No, we should not always make unauthenticated DID resolution requests (all DID resolution requests should not be unauthenticated).

Both unauthenticated and authenticated DID resolution requests should be tested.

OR13 commented 2 years ago

IMO, all our tests should require authentication, when we expect it to be used in a production use case...

there are "open world" api scenarios we might consider, like the interactions between CHAPI and the presentation exchange APIs.... but thats probably better handled on a separate issue.

mkhraisha commented 2 years ago

I think we should switch to authenticated endpoints for all did-resolution postman tests.

OR13 commented 2 years ago

Consensus is that everything should be authenticated.

We can close this when we have negative tests that confirm that all endpoints require auth.

OR13 commented 2 years ago

We think

/presentations/available and /presentations/submissions should NOT require authentication.

We think all other endpoints should require authentication with scopes.

See: https://w3c-ccg.github.io/traceability-interop/openapi/#auth

BenjaminMoe commented 2 years ago

I agree with: https://github.com/w3c-ccg/traceability-interop/issues/187#issuecomment-1129181211

Edit: For the other end points. I don't know if it's necessary to formalize authentication. We have a resource like did:actor which allows anyone to make unauthenticated requests as a public service. In the case of DID resolution, it seems like it's up to the administrator to decide if they want to offer the end-point as a public service or not.

BenjaminMoe commented 2 years ago

Objections on the call was the the description needs to be updates, and we need to provide a list of end-points on this issue and provide a list of end points, and then provide rationality for why we think authentication should be required or not.

There's a second aspect of optionality. I agree that as a spec that we should avoid optionality. So we should provide rationale for how authentication could be applied if not required.

TallTed commented 2 years ago

I believe there are legitimate use cases where /presentations/available and /presentations/submissions SHOULD and SHOULD NOT require authentication. Design must therefore support authentication and support admin switching it off (a/k/a accept any authentication offered).

I believe that similar will be the case for all other endpoints -- i.e., that requiring authentication should be the default (and thus this should be tested) and disabling this requirement should be an admin option (and thus this should also be tested).

OR13 commented 2 years ago

My comment is limited to these 2 endpoints: /presentations/available & /presentations/submissions

use case 1

Alice finds Bobs DID on the internet. Alice resolves Bobs DID, and sees it supports /presentations/available and /presentations/submissions. Alice tells bob she wants to introduce herself. Bob's server replies with domain and challenge. Alice signs a Verifiable Presentation over the domain and challenge, containing her verifiable business card. Alice submits the Verifiable Presentation to Bob.

At the end of this flow, Alice has authenticated to Bob via DID Auth and presented credentials.

use case 2

Alice finds Bobs DID on the internet. Alice performs dynamic client registration to get an OAuth2 token. Alice does the same flow from step 1, but with OAuth token securing every network requests.

use case 3

Alice finds Bobs DID on the internet. Alice establishes an mTLS connection with Bob. Alice does the same flow from step 1, but with mTLS securing every network requests.

use case 4

Alice finds Bobs DID on the internet. Alice gets a ZCAP (JSON-LD Object capability, not a verifiable credential, but looks like one.) Alice does the same flow from step 1, but with ZCAPs securing every network requests.

use case 5

Alice finds Bobs DID on the internet. Alice gets a DPOP for Bob Alice does the same flow from step 1, but with DPoP securing every network requests.

use case 6

Alice finds Bobs DID on the internet. Alice gets a GNAP access token for Bob Alice does the same flow from step 1, but with GNAP securing every network requests.

use case 7

Alice finds Bobs DID on the internet. Alice does the same flow from step 1, but using DIDComm to secure every network requests.

Conclusion

Use case 1 just does DIDAuth, all the other use cases also do DIDAuth, but use another auth system to restrict "who can do DID Auth".... as @TallTed noted, there are use cases for using DIDAuth with OAuth... an obvious one would be, use OAuth with https://login.gov/ and then do DIDAuth so the government can associate a subject identifier to your DID.

If you know the parties that will be exchanging data, and you don't need DIDAuth, you can just use OAuth. If you don't know the parties you can require them to become known first, and then use OAuth. If you want to authenticate the parties exchanging data twice (collect more data on subjects), you can use DID Auth and OAuth together. We could also do mTLS, DPoP, ZCaps and OAuth first and then DID Auth.

The VC API (and indeed any Apache-2.0 project) can be forked, nobody can stop someone from implementing all of these strategies or only 1 of these strategies.

Accurately documenting the proper use of each strategy and the security and privacy implications for each will take time.

I suggest we focus on documenting strategies we intend to support in production.

For the next year, Transmute is not planning on supporting any of the cases other than 1 in production (for these endpoints).

I recommend we not add authentication to /presentations/available and /presentations/submissions because I believe they should be open to anyone, and stay as close to the VP request spec and CHAPI behavior as possible, and CHAPI does not have the "double auth" behavior.

I recommend we implement a new endpoint that does require OAuth and scopes, and that takes verifiable presentations without a proof. If that endpoint were not secured with OAuth (or something else), there would be know way to authenticate the holder.

I like the design pattern of:

Use /presentations/available and /presentations/submissions when you want to allow unauthenticated requests to establish a Verifiable Presentation with a proof of DIDAuth.... OAuth Forbidden.

Use /oauth/presentations when you are already authenticated and want to send a verifiable presentation from a holder to a verifier in a single network request.... OAuth Required.

See this issue for discussions regarding that new endpoint: https://github.com/w3c-ccg/traceability-interop/issues/95

I expect we will likely deprecate the "DIDAuth" endpoints in favor of OIDC 4 VP eventually... another reason not to invest a lot of time and effort into testing them with and without many alternative authentication schemes.

See: https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html

nissimsan commented 2 years ago

I completely agree, @OR13. I was just writing this:

TallTed commented 2 years ago

from @OR13's use case 1 (https://github.com/w3c-ccg/traceability-interop/issues/187#issuecomment-1130042940)

Alice resolves Bobs DID

To my eyes, that says "Alice requests resolution of Bob's DID" which I think is an unauthenticated request, given that authentication gets discussed later in that use case. This DID resolution request is entirely independent of /presentations/available and /presentations/submissions because Alice doesn't know those endpoints exist until after Alice has resolved Bob's DID.

It's kind of like DNS resolution to IP address, which is typically unauthenticated, though any service requests (e.g., ssh, ftp) made to that IP address may require authentication (or may not, e.g., http).

OR13 commented 2 years ago

To my eyes, that says "Alice requests resolution of Bob's DID" which I think is an unauthenticated request, given that authentication gets discussed later in that use case.

I focused my comments on /presentations/available and /presentations/submissions intentionally.

We can discuss security considerations of the other endpoints on a separate issue, each endpoint likely requires different scopes / attention.

... but you are not correct that "DID Resolution" requires "network requests" ...

HTTP is just 1 way of doing DID resolution... you don't need to make any network requests to resolve did key, and you don't need a "trusted resolver" to resolve did web.

In fact, if you are really paranoid (or a really high value target), you would avoid ever using any resolver other than one you operated yourself.

Because the network logs of resolvers leak information about the metadata of credentials (issuer and holder timings).

See also, https://www.justice.gov/usao-sdny/press-release/file/1486816

Between on or about December 29, 2021 to on or about January 19, 2022, the LLACUNA Home IP Address was used more than 130 times to conduct activity on social media platforms, including Discord and Twitter, which were used to promote and discuss the Frosties NFT sale. On at least 13 occasions during this time period, the LLACUNA Home IP Address was used to log into the Twitter account named @FrostiesNFT. As described further below in paragraph 17(f)(i), the LLACUNA Home IP Address was also used to conduct transactions relating to a new NFT project linked to NGUYEN and LLACUNA.

In this case, ISP ~= Resolver.

TallTed commented 2 years ago

@OR13 -- The title (and initial comment) of this issue should be our starting point.

"Should all DID resolution requests be unauthenticated?"

That does not specify did:key, nor any other specific method, which I think is appropriate for this question, and its answer.

did:key is one method, for which DID resolution does not require an authenticated request nor unauthenticated request (nor any request, in fact).

did:web is another method, for which DID resolution does (I think) require a request, but does not require that request be authenticated nor that it be unauthenticated.

I'm sure there are or will be some methods which always require authentication for DID resolution. There may well be some which always require unauthenticated requests.

OR13 commented 2 years ago

"Should all DID resolution requests be unauthenticated?"

This is what the spec says today:

https://w3c-ccg.github.io/traceability-interop/openapi/#get-/identifiers/-did-

Screen Shot 2022-05-18 at 11 09 51 AM

Other profiles might make different decisions.

I think the current spec definition is correct.

If you like, we could open an issue per endpoint defined in the spec, and debate the following on a per endpoint basis:

  1. Is OAuth required.
  2. If OAuth is required, are scopes required?
  3. If Scopes are required, what must their values be?
OR13 commented 2 years ago

I can also update the title and description of this issue to focus it on GET /identifiers/{did}.

Or close this issue, and cross link to a new issue per endpoint.

nissimsan commented 2 years ago

Discussing on the call: the three /presentations endpoints are the important ones to cover here, dealing directly with interoperability.

nissimsan commented 2 years ago

Consensus to close this general ticket when individual per-endpoint issues have been opened.

BenjaminMoe commented 2 years ago

Since the other issues have been opened, i think this issue is safe to close.

Edit: Closed by mistake.

nissimsan commented 2 years ago

Closing this, moving the discussion to the individual issues.