Do the `/exchanges/*` endpoints need authz?

At present, the /exchanges/* endpoints are being implemented to have optional authz. That is, implementers can add authz to those endpoints if their use cases require it.

At least one implementer does not require authz for performing presentation exchanges, but rather does authn/authz in the /exchanges/* protocol itself. One use case has the Issuer implementing the /exchanges/* endpoint, a Holder engaging with the endpoint, and the Issuer responding with a DIDAuth request to authn the Holder. This does not utilize OAuth2 to establish software client authz.

This approach has been challenged to be insecure, so this issue is to discuss the attack models and security characteristics of this approach.

If we take the purpose of registration in OIDC to be the ability for the wallet to express what it supports so that it obtains a VC it can actually use...

I've been trying to make it really clear that it's important to separate that out. It's not needed for the security model in CHAPI + VC-API but it is in OIDC.

If we want to talk about UX, etc. -- that's fine, but it's a separate subject. How we solve particular problems there may have a number of different possible solutions, each with advantages and disadvantages. If we come up with a more elegant solution to a UX issue than "client registration", OIDC still needs registration for its security model; that's important to note.

It is true that if we find that some element that is needed for some protocol's security model has good trade offs when reused to solve a UX problem as well -- that's great, but we need to be more rigorous in saying what things are for, why they are necessary, what the trade offs are, etc.

...then I dont believe this isn't needed in the CHAPI + VC-API, it may mechanically be achieved in some other manner but its a stretch to say that the way it chooses to achieve this is an overall reduction in implementation complexity.

It absolutely is a reduction in complexity (and attack surface). The effects of security bugs are not the same as compatibility bugs, just as another simple example.

@mavarley,

PS: I will note that in step 2 in the diagram in https://github.com/w3c-ccg/vc-api/issues/279#issuecomment-1085175331 this call is likely authenticated/authorized and results in the exchange-id as a bearer token, which is also acting as the authorization to execute the exchange API -- seems like we danced around a lot, but the VC API still requires authorization ?

It doesn't require "client authorization" (read: wallet authorization). There's an expectation that any backend service that the issuer uses would either have authorization of some sort or be behind a firewall, etc. -- but none of this is relevant regarding whether a user's wallet of choice now needs to be authenticated and/or strongly identified to the issuer. That's a total different requirement.

@mavarley,

I am not suggesting all CHAPI flows need to change to the above; merely exploring possibilities.

Yup, +1 to your example of a "tighter subject binding" that shows one way that the primitives provided via CHAPI + VC-API can be composed to achieve a particular use case.

@mavarley,

This is where I am weary - "there is no way that could happen" is a great opportunity for "bad actors" to find a way to break those assumptions. So then these attacks become a question of scale, not possibility. Break CHAPI and steal everyone's credentials? Bad and highly scalable. Break CHAPI, and subvert an out-of-band session binding (like PKCE or SMS code or ...) Bad, but less scalable. Break CHAPI, subvert an out-of-band security token, and impersonate a trusted holder software implementation ... well, diminishing returns maybe but you see how this goes.

This is a different kind of attack that assumes the security model is broken. The CHAPI + VC-API security model assumes CHAPI is secure. It's similar to assuming that wallet, RP, and issuer software are secure in any other case (like OIDC). If you don't have client authentication in the OIDC case, even if those other things are secure, there's an attack. If you don't have client authentication in the CHAPI + VC-API case, there's no attack. That's what my statement meant.

If we want to talk about "how to improve the security of the CHAPI mediator itself", I think that's an interesting topic of discussion, but it's a different discussion. Again, I think we need to be more robust with the layers at which we're making comparisons here.

That being said -- on the topic of "improving the security of the CHAPI mediator itself" -- the above attack you mentioned could be mitigated in an interesting way:

RP publishes a did:web DID with a keyAgreementKey.
RP calls CHAPI with a request for VCs.
User picks a wallet.
Wallet checks RP for a did:web DID; if found, encrypts the VP response via its keyAgreementKey.
CHAPI forwards the encrypted response (it cannot be read) to the RP.
RP decrypts the response.

Note that this still can all be done without any "client authentication / identification / registration".

@mavarley,

Something I think CHAPI + VC-API does moderately well is keeping role responsibility clean. For example, with CHAPI + VC-API, a wallet is a user's trusted agent and it handles consent and helping the user make decisions, and it's up to an issuer to provide an interface for taking a user through a process for obtaining a VC (which may include any number of interesting issuer / VC specific steps).

Same as OIDC? That's what the redirect does?

No, the OIDC flows we've seen require the issuance process to start via an unbounded public VC selection list published by the issuer that is downloaded by the wallet and rendered in a "wallet marketplace". The issuer must use this primitive to issue their VCs. I detailed a number of problems with this approach in my post. The biggest one is that the issuer loses their ability to manage the user relationship, experience, and eligibility checks at the start of their issuance process. We could end up with issuers giving their users instructions like this:

"Ok, once you choose your wallet, make sure that you scroll down to pick 'Greenwood Commons VC' in your wallet marketplace, not 'Common Greenwood VC', otherwise you'll have to do this again. Also, make sure that you have VC X, Y, and Z if you're going to pick 'Greenwood Commons VC', otherwise you'll have to go back and pick 'Albatross Greenwood Commons VC'."

This is why I suggested that having the user choose "flows" at the wallet marketplace may be better. But even then -- maybe issuers will just show one choice -- because they want full control over the process -- and it becomes a wasted part of the UX. Hopefully this makes better sense now.

@mavarley,

Maybe that was directed at @tplooker who has expressed these concerns, but I believe the comparison is:

In a CHAPI based flow, the Issuer and subject interact / authenticate / qualify, and then the wallet gets involved. "All set, pick your wallet". Then the individual is left searching for a qualified wallet (maybe they didn't have one and need to get one before their web session expires? Maybe they had one but it doesn't use the same did/crypto profile and need to find a new one? But they've gotten this far!! "Figure it our fast or your session is cooked and you start again!" is pretty stressful)

In an OIDC flow, the Issuer and holder-software can establish compatibility before the subject does any hoop jumping. In other words, step 1 is the client/wallet contacts the issuer and checks its qualifications. step 2 is authenticate/qualify/etc... and the conclusion of the process is a credential is fetched by the holder software.

Like I said in my other comments, there are not just wallet eligibility concerns, but also user eligibility concerns. I tend to think that user eligibility should be prioritized over wallet eligibility. Reasons:

Another wallet can always be offered (unfortunate, but a possible solution) if a user gets to a point in a flow where they can't use their existing wallet. A user can't "become someone else" to solve the user eligibility problem after they've picked their wallet and started down a flow that they can't complete.
The user can understand that their wallet is incompatible and it's not their problem -- and they may be able to use this information to persuade their preferred wallet provider to become more compatible (maybe this is achievable even if the wallet is chosen first).
There are N-many ways a wallet could be incompatible. Most wallets will try to be compatible with whatever is popular -- and there are only so many popular DID methods and cryptographic suites. In a more mature ecosystem, this problem should be very rare. The number of ways that a user could be ineligible for a particular flow / VC is, by comparison to N, essentially unbounded -- with each issuer having any number of unique constraints -- and maturity of the ecosystem doesn't necessarily reduce this at all.

No, the OIDC flows we've seen require the issuance process to start via an unbounded public VC selection list published by the issuer that is downloaded by the wallet and rendered in a "wallet marketplace". The issuer must use this primitive to issue their VCs. I detailed a number of problems with this approach in my post. The biggest one is that the issuer loses their ability to manage the user relationship, experience, and eligibility checks at the start of their issuance process. We could end up with issuers giving their users instructions like this:

To be clear OIDC Discovery is never required its just a method to support this style of issuance when desired the credential offer sent to the wallet could equally be (note this is just an example)

openid://discovery?issuer=https://example.com&credential_type=university_degree

The wallet can then if it desires just skip ahead straight into an OIDC request with the openid_credential:university_degree present in the list of scopes, the publishing of the metadata just supports pre-discovery of what will be in the credential if it is desired.

@mavarley,

I might argue that your initial assumption is incorrect. I would not build a workflow the subject cannot complete without an OIDC exchange later. Instead, the workflow starts with OIDC. Or, the workflow completes successfully (with maybe a printable VC?) and the subject is presented with an option to load it into a digital wallet (which may require another login, but the workflow is clear). So, counter example:

The user arrives at an Issuer site that issues Verifiable Credentials. The page describes the process and the wallet requirements (if any).

The user takes an action (click a button, scan a qr) which tells their wallet to contact the issuer to begin the flow.

But which flow? In the diagrams we've been given, there's no way to whittle the choice down, but, as mentioned, an unbounded list of VCs is shown in a "wallet marketplace UI". I do tend to agree that issuers will end up abusing this primitive such that there's only one choice -- or very few choices -- because they will want to be in charge of this selection and where the flow heads on their own site.

OIDC discovery, and possibly dynamic registration occur. At this stage, incompatible wallets indicate to the user, "sorry, cannot proceed" -- the user is disappointed but has invested very little.

Yes, the user will have invested very little. But if they make a choice and move forward -- and that choice isn't "the right one", they will be very annoyed.

Again, this implies that issuers, in order to avoid this, will abuse the "public VC selection list" primitive not to show actual possible VCs the user could get, but instead would make each item in the "VC list" be a representation of "all flows that require wallet features X" instead. This may be awkward for users -- have we considered what it would be like? It seems the flow in the diagram may be optimized for demo sites or small / one-off issuers.

What I'm saying is that the primitives feel off here and it's a result of taking away responsibilities from the issuer. Is that making sense?

If registration is successful, the wallet redirects the subject to the issuer's authentication and qualification process web workflow (same as what exists in pre-CHAPI flow). This includes specific consent related to an active workflow, not a future possible workflow.

To further analyze whether the primitives and their semantics are right here ... what use was the "public VC selection list" in this flow? What does having it accomplish?

At the completion of the application, the user is directed back to the wallet (where further action/consent can be collected and managed). The wallet pulls the credential from the issuer using a security token bound to an authenticated workflow.

The above is not perfect, and may have gaps that are currently being worked on wrt. required presentations etc; I will note that the above can also enable a direct wallet-to-issuer VPR communication exchange, but interact is not necessarily required, as presumably all the interaction has already occurred.

How does the wallet know when the exchange has ended? Does it assume it's over based on receipt of a VC? Is that what is meant by "presumably all the interaction has already occurred"? What if there are more VCs for pickup and more to do in the exchange -- how does the wallet know how to direct the user next? There seems to be a missing primitive that clearly marks the end of the exchange; instead, it seems to be presumed. I'm worried about composability here.

@tplooker,

To be clear OIDC Discovery is never required its just a method to support this style of issuance when desired the credential offer sent to the wallet could equally be (note this is just an example)

openid://discovery?issuer=https://example.com&credential_type=university_degree

The wallet can then if it desires just skip ahead straight into an OIDC request with the openid_credential:university_degree present in the list of scopes, the publishing of the metadata just supports pre-discovery of what will be in the credential if it is desired.

Then I would recommend eliminating the "wallet marketplace" option entirely, instead requiring an approach that mitigates the concerns I've raised.

Side note: I think I've also lost the thread here on how the user makes a compatible wallet selection or where / how the required wallet features are expressed. I'll see if I can find it in the issue here if it's already been said -- otherwise, could you elaborate on that part?

Then I would recommend eliminating the "wallet marketplace" option entirely, instead requiring an approach that mitigates the concerns I've raised.

Im not sure why eliminating it is required, if its optional and services other usecases why would we remove it? what does it prevent you from doing that you want to be able to do? I also dont really it as a "wallet marketplace" its just a way for a provider to advertise what credentials it supports issuing

Im not sure why eliminating it is required, if its optional and services other usecases why would we remove it?

We should eliminate it as a part of a core protocol because of ecosystem complexity. We should be trying to optimize for the minimum number of primitives that achieve the maximum number of use cases. Then we should pick primitives that can be layered/composed to maximize the next band of use cases.

I've noticed a pattern in the discussion (that we're all guilty of), of just referring to technology X to solve problem Y... and we're picking and choosing each technology and saying they are "optional". Ok, fine... but what's the baseline that everyone is expected to implement and how many use cases can we achieve at that baseline?

IOW, it's always possible to tack on optional technologies... OIDC4VCI + OIDC Discovery + SIOPv2 + DPOP + PCKE ... or VPR + VC-API + did:web keyAgreementEncryption + ... and when we do that, we tend to just go around and around in circles because... if you can solve a problem using one technology, it's probably true that you can solve the same problem using a different technology plus adding a bunch of add ons.

Person A: CHAPI enables user-driven mediation. Person B: Oh, but OIDC could use CHAPI to achieve the same thing! ... but what about cross-device QR Codes, VPR can't do that. Person A: VPR could use did:web keyAgreement to achieve that! ... but what about ...

and around in circles we go. How can we structure this conversation so that we start converging? Would it be helpful if we state things that need to be a part of the core interoperability profile?

Can we start with "Mediation is a mandatory part of the core protocol?" -- I only offer that because it seemed like @tplooker agreed to that on the CCG mailing list... and I don't know where @mavarley is on that right now.

I'm asking because I'm at a loss right now.

Person A: CHAPI enables user-driven mediation. Person B: Oh, but OIDC could use CHAPI to achieve the same thing! ... but what about cross-device QR Codes, VPR can't do that. Person A: VPR could use did:web keyAgreement to achieve that! ... but what about ...

Just a +1 to this comment.

Can we start with "Mediation is a mandatory part of the core protocol?"

(big apology in advance and asking quietly...) what do you mean by Mediation? I only ask because SK uses the term internally in several different ways...

As per #181 there may be scenarios where Mediation is not required? Do you mean an intermediary protocol for connecting wallets to service /exchange/ endpoints when dealing with session specific data?

Can we start with "Mediation is a mandatory part of the core protocol?" -- I only offer that because it seemed like @tplooker agreed to that on the CCG mailing list... and I don't know where @mavarley is on that right now.

I think the disconnect here is that OpenID CP / OIDC4VCI doesn't always assume that you start from a channel, like a browser that requires mediation. Instead you could be scanning a static QR code from a piece of paper that contains openid://discovery?issuer=[https://example.com&credential_type=university_degree], hence having information at the providers metadata endpoint to tell you more about what auniversity_degree credential is, is useful in those cases. Designing a protocol that mandates that IMO is a layering violation and just means we would have to have another protocol when mediation isn't required.

(big apology in advance and asking quietly...) what do you mean by Mediation?

Yes, that was covered here: https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0010.html

Excerpt below:

On 4/3/22 2:06 PM, Brian Richter wrote:

Manu, can you define "mediators" in this discussion?

Yes, we need to find a better term... even "wallet mediator" isn't descriptive enough.

A "mediator", as used in CHAPI, is a piece of software that enables a Holder to choose which "digital wallet" they want to use for a particular transaction. This is in stark contrast to how social login works today, where you are typically only given 3-4 fixed/centralized choices: Login with Google/Apple/Microsoft/Facebook

A mediator typically supports registration, selection, and deregistration. It also has other properties, like preventing an Issuer or a Verifier from discovering what Wallet the Holder is using (one strategy for preserving a competitive ecosystem).

A mediator is what enables digital wallet choice in the SSI ecosystem when you want to invoke a digital wallet, regardless of whether it is a web app or a native app, on the same device (such as your laptop). A mediator is agnostic to the messages flowing over the communication channel.

At present, CHAPI is used in the Verifiable Credentials ecosystem to select a wallet provider. It could also be used to select from among your OIDC providers.

In Aries / DIDComm land this term is used for agents that route messages to agents that are often offline however I suspect you are using it in a different way.

The meaning in CHAPI is slightly different. CHAPI is used to route messages to agents without a consideration to whether or not they're offline (e.g., CHAPI can work in both offline and online scenarios since it's purely client-side technology that lives in the browser).

@tplooker wrote:

I think the disconnect here is that OpenID CP / OIDC4VCI doesn't always assume that you start from a channel, like a browser that requires mediation.

Yes, true (though that point was never lost on me)... and this is one of the problems w/ the current conversation. In fact, I call out exactly the statement above in this comment. You are "whatabout"ing cross-device QR Codes (which DO need some sort of protection) when we haven't established whether you believe "wallet mediation" is required in same-device digital wallet invocations. That is, you're talking about a cross-device use case without us all getting on the same page about the same-device use case. I feel like we're close to getting on the same page about same-device use cases... can we run that to ground first?

We might try to start focusing on one class of use cases (e.g., same device wallet invocation) and come to some conclusion on the simplest/minimum primitives needed for that use case, and then moving on to another one. I do admit that we need to think about all of this holistically... however, that is leading to us talking in circles (sort of, I also admit that we're making progress with every circle -- this process was bound to be messy).

Can we run the "Is mediation required for same device wallet invocation use cases?" to ground? If we answer that question, we might be able to answer the question raised in this issue. To be clear saying "Yes, wallet mediation is required for same device wallet invocation use cases." does not require one to pick "CHAPI/OIDC/VC-API/VPR/etc." -- it's just an acknowledgement that we value addressing that use case. Digital Bazaar values that use case because we have customers that require the ability to invoke both native wallets and web wallets in same-device flows.

I dont think whether we are using a mediation component like CHAPI as a way to establish a communication channel between the wallet and issuer should be core to the protocol design here, instead it is an important layer above the protocol. If we make it one, we risk designing a protocol that only works over CHAPI and I disagree with that intent. Where components like CHAPI become important in this particular conversation is the trust and assurances it provides as a channel to allow an issuer to communicate with a wallet.

I believe it is better to start this protocol design from the perspective of an untrusted channel between the issuer and wallet, rather than trusted (e.g CHAPI). Because designing a protocol based on the former will mostly likely mean the flow will also work over a trusted channel like CHAPI, its just perhaps not as optimised. Whereas if you start from a world view that the channel must be trusted, chances are the assumptions in the underlying protocol will be invalid for the cases where it is not, hence causing a revisit of the core protocols design.

To answer your question directly Manu, I do see huge value in same device based flows through a mediation layer, however I think starting with these as the core requirements, risks designing a protocol that only works in that case.

Bringing in a conversation from another thread where we had talked about protocol intents and layering:

We have:

Locators (Mediators as per https://github.com/w3c-ccg/vc-api/issues/279#issuecomment-1094063697)
Discovery protocols (now that we've found each other, can we communicate?)
Subject-to-wallet-to-session-binding (is there an an assurance the wallet operator is the same entity as the issuer/verifier session operator?)
Credential delivery: (now that we can communicate and have a trust framework to operate in, how do I send you requests/presentations/etc?)

Examples: Wallet locator: CHAPI, protocol handler, registered selector, QR Discovery protocol: VPR, OIDC dynamic reg., WACI introduction Subject-to-wallet-to-session binding: OAuth/OIDC (url) (and,or) credential presentation, N/A Credential delivery API: VPR, OIDC-CP, WACI

Not all of the above are necessarily required for all interactions.

Can we update the title?

I'm not sure we are still talking about /exchanges/* endpoints.

If we are, can we can an enumeration of those endpoints, including the components on which those endpoints are expected?

The group discussed this item on 2023-01-17. It was noted that many months have passed since this topic was discussed and in the meantime flows have been added to the OIDC4 flows that do not require registration or allow dynamic client registration. @dlongley noted that we should have authz for the creation of exchanges endpoints but should not require authz for the usage of the endpoint you create. @dmitrizagidulin agreed with a +1, authorization for using the exchanges endpoint should be optional because there are several valid use cases where authorization is done inband as a part of the exchange... DCC learner credential wallet uses such a flow... this is different from having authz on the API endpoint itself. Alan Karp noted that for administration, you will probably have authz. For public endpoints you almost never want to have authz, unless you want protection against DoS, in which case you went to other endpoint first, get an authz credential, and then provide that to "public endpoint". You absolutely don't want authz REQUIRED for a public endpoint.

@jandrieu noted that he was still confused about what exchanges is doing, so difficult to comment on technical ramifications, but noted that those implementing it find it useful. Why isn't it just a token passing when you have an endpoint that you hit and you get a "you need to get something else" -- who is telling whom that a flow is going to happen... and then "you need these things for this flow". @TallTed noted that he was confused as well -- designing things to not require authz has a high potential for security issues down the line -- in most deployments, this might not be necessary (especially in test), perhaps some kind of tokenization needs to be involved. When you come to newly created endpoint, you have to have token from person that requested endpoint. @dmitrizagidulin explained what /exchanges/ endpoint was... there is a need for iterative credential issuance/reissuance -- so endpoint belongs in issuer endpoint, but closer to issuer rather than verifier -- idea is it's a multistep way to provide credentials, where issuer can, in stages... "before I can issue to you, I need X, Y, and Z -- and might include authz" -- reason to do authz on application level is to allow discovery, to allow exchanges endpoint to specify which VCs/authz it needs to issue/reissue a VC. @dlongley noted that this isn't necessarily on issuer coordinator component... end user is using issuer coordinator website, via that interface, they make a decision to request a VC, upon that request, issuer coordinator creates exchanges URL that follows process that wallet needs to go through, hands that exchanges endpoint to wallet, which then (gets into authz discussion), URL could be seen as an authz capability (unguessable URL and only someone who's been handed the URL can go to the endpoint and proceed). When they hadn that off to a digital wallet and visit the URL, that URL might ask them for additional VCs... endpoint could be implemented on issuer coordinator to allow custom code, or could be implemented through external exchanges service that operates on basic primitives -- some flows can be easily constructed form a set of VPRs and VC templates, other flows cannot. It depends on the type of flow the user is going to end up going through. That's how exchanges set of APIs should be understood. @PatStLouis noted that exchanges service makes more sense now, in case of Aries, typical flow is credential offer, then credential request, then issuance. Issuer offers VCs, Holder requests it, Issuer issues it. How that language is used here "issue" -- signs the VC, adds the proof, previous to that "issuing" had the whole flow "to sign a VC and send it to wallet". Exchange service in VC API is whole communication between holder and issuer so they can understand how to exchange information, hopefully at end of implementation, Holder has VC in the wallet. Regarding authz, there is the concept of discovery, wouldn't discovery be treated separately? Unauthenticated endpoint that says "Here are the 'languages' that I can speak, which of these interactions would you like to begin? There are the functions I support, is that the type of discovery endpoint that the issuer can provide?".

@jandrieu Why not just as a response when you try to get a credential issued and you hit the issuer, why not use a redirect pattern, which is a more common pattern on the web? @dlongley noted that redirects don't work, you might not want to lose state, you might need to go to different device, different app, that pattern doesn't cover everything that needs to happen. @jandrieu didn't mean literal HTTP redirect, he meant the use of the interact field in the VPR. @dlongley noted that's exactly how it's implemented today (in CHAPI and some VC API exchanges). @dmitrizagidulin noted that the reason it's not done through /issue endpoint, if it was named literally, it would be an /add-proof endpoint... @jandrieu noted we're not talking about issuer service... @dmitrizagidulin said you could look at the exchanges endpoint as living on the issuer coordinator. The exchanges endpoint is meant to interact w/ wallets, very much a public endpoint, hence the optional authz, when credentials expire and wallets want to expire, they would talk to exchanges endpoint, when wallet wants to request particular VC, they'd use exchanges endpoint. @PatStLouis said that @dmitrizagidulin the /issue endpoint is an "add proof" endpoint, issuing credential has a different meaning in Aries as it does in VC API -- ACAPy admin interface has a specific endpoint, different endpoint for issuing credential, in issue credential endpoint, different endpoint for every step of flow, same thing for verifier endpoint. At one point, in one of the steps, you choose if you want to issue AnonCred or JSON-LD VC, but endpoint is strictly signing a credential. @dlongley noted that the /issue endpoint is more than just signing, for examples, it adds status list information -- creates a true instance of credential and updates backend state management. An endpoint example, we have WebKMS, just for making calls to sign/verify via cryptographic operations, those endpoints are stateless and don't care about what is being signed (just sign a hash), whereas /issue endpoint is responsible for that in VC API. @msporny noted that this can show up on issuer coordinator, verifier coordinator, and holder coordinator. @jandrieu noted that when refreshing, you'd use credentialRefresh property on VC not something "discoverable". Why do we have to go to exchanges endpoint, why can't we do everything w/ interact vs. saying coordinator they have to have this mechanism? @dlongley noted that you don't have to have this endpoint, they can model their URLs however they want to, refresh could go to exchanges endpoint, but could go elsewhere -- depends on refresh type -- those are all open options. The /exchanges/ API provides a common interface that people can write software against - a common architecture for software reuse. What we do w/ the other endpoints, there is a common pattern, because of common pattern, gives architecture for developers to develop against. @PatStLouis wanted to note about /exchanges/ endpoint could be on Holder... we talk about Holder, Verifier, Issuer -- which are roles, specific agent has in a specific interaction, mobile wallet, issued a VC, in that interaction I'd be holder, but isn't it forseeable that agent could be in a different interaction become an Issuer using same technology behind it. @msporny noted that we definitely have this on issuer coordinator and verifier coordinator, holder coordinator is a still more up in the air. @PatStLouis noted that roles bind when you are doing an interaction and only then, the VC API, every implementation should have all the routes available. @jandrieu one of the things we documented in the component diagram, the arrows show initiation of flows, which are from the holder... callbacks, async, holder provides callback from verifier, would be hesitatant to have endpoints on holder, could be attack vector. @dlongley didn't quite understand what the use case is for exchanges on verifier coordinator, would expect to be on issuer coordinator, perhaps something not a VC is being presented back to you for verifier coordinator? Not aware of a use case. @PatStLouis directly to what Dave said, couldn't verifier send a holder a proof request that would be a tangible thing sent through /exchanges/ API? @dlongley There is confusion around what it means to have issuer coordinator/verifier coordinator to be the same thing? You end up in a situation where a verifier is an issuer and becomes a verifier again -- a bit confusing trying to understand when we say exchanges endpoint could be on a verifier coordinator, also means verifier coordinator could also be issuer coordinator, if you get a proof request, you have to use it, perhaps we're saying you might use it on another service/system? Not quite sure. John Henderson noted, on user exchanges for verifier, found myself where Holder wants to get access to a service, so they ask / discover exchange endpoint and present credentials and are authorized having credentials used to those service, not receiving a VC in return, see it as holder exchaneges w/ verifier.

@PatStLouis noted that something doesn't sound secure about this. @msporny noted that this works just like a regular website, which doesn't have authz on the first hit. @dmitrizagidulin noted that these are exchanges under opaque strings, this is a specific opaque exchange that usually the wallet arrives at out of band. @tallted if this is equivalent to homepage optional activation seems ok, but making it optional endpoint, they might not implement this authz piece they might change implementation because they discover they need that -- make the /exchanges/ endpoint mandatory to implement -- feels like a thing that should be there. @dlongley noted that what we should say is: "A given exchanges endpoint should be a URL capability or establish authz through exchange flow itself." @msporny asked if there was ever a use case where the previous sentence didn't fit? @dlongley noted that there is always authz -- like "number of bearer tokens that can be given out". Alan Karp noted that you do that if there is a DoS, if it's a public endpoint, if you want people to use this as their first interaction w/ the system, how do they get the initial authz -- if it's a piece that you only make sense to contact after you've been using other pieces of the system, makes sense to always have authz. @dlongley noted that we're really talking about the latter, URL capability or authz established within flow itself covers this -- what we were worried about was saying that "if you were given URL capability, do you also need to use OAuth2 to use the exchange endpoint" and the answer to that is clearly "no"... we're crossing trust boundaries. Totally different party thats accessing /exchanges/ endpoint using digital wallet.

@msporny asked if anyone had concerns about "A given exchanges endpoint should be a URL capability or establish authz through exchange flow itself." Alan Karp noted not an objection since we're talking about "private endpoints". @msporny noted it's not necessarily private, you have to interact elsewhere. @dlongley noted that there are multiple options here where you could get the capability URL. Alan Karp noted that you don't need authz to hit it the first time. When it's part of a flow, you get capability to invoke.

We discussed this on the 2023-01-24 telecon. @jandrieu noted that there are at least two things of concern 1) difference between endpoints, between issuer coordinator and verifier coordinator and verifier service (secured thorugh some mechanism) vs. verifier coordinator needs auth or not. 2) Establishing authz through exchange flow is still having authz on that exchange flow. @dlongley thinks what Alan was saying fits into quote above... "A given exchanges endpoint should be a URL capability or establish authz through exchange flow itself." -- either there is a case where you are using a URL capability (it's not advertised and sufficiently randomized to not guess URL), or case that there is a "public" URL, anyone can hit that, when you hit that URL, you get a VPR that you must respond to and in so doing, some sort of authz is going to be established through the exchange flow. @dlongley feels like quote covers both cases. Either it's a URL capability (authz by holding the capability) or authz is established upon interaction. @msporny asked about "first come - first served" use cases? @dlongley noted that even in those cases, authz of some kind will be done to prevent DoS, or limited number of credentials to be given out, one over limit - rejected, implies some sort of control over using endpoint. @jandrieu noted "proof that service is running" doesn't fit into that use case. @dlongley noted that even in that use case, it'll probably be rate limited.

@msporny noted that if we enumerate all the possiblities, if we answer the question? @dlongley and @jandrieu noted that if we go endpoint-by-endpoint, we answer this question.

The next step for this issue is to close the issue once we assign what types of security are on an endpoint.

The group discussed this on the 2023-04-11 telecon:

The group has set available security schemes for all endpoints in PR #334, which addresses part of this issue.

The next step is to raise a PR to refactor exchanges as a first-class component and explain how exchangers are created/configured and then how exchanges are built off of exchangers.

Waiting for #353 to land and then will build off of whatever text is added to the spec as a result.

w3c-ccg / vc-api

Do the `/exchanges/*` endpoints need authz? #279